Kitobni o'qish: «Agile. Процессы, проекты, компании»
© ООО Издательство «Питер», 2020
© Серия «IT для бизнеса», 2020
© В. Фунтов, 2018
Предисловие автора к изданию
Agile как мышление, или комплекс подходов, или как организация корпоративного управления, в настоящее время должен быть известен всем, кто занимается какими-либо проектами или процессами в современной компании или лично. Agile должен широко применяться тогда, когда важно пошагово наращивать ценность результатов или продуктов, правда, с определенными, иногда принципиальными ограничениями в использовании. По Agile можно разрабатывать коропоративную стратегию, проводить эксперименты с новыми идеями, вести совместное с заказчиком проектирование, строительство и даже создавать автомобили и самолеты. Но Agile, к сожалению (а может, просто пока), неприменим в формализованных, чувствительных к жизни людей производствах и системах, при капитальном строительстве, военном приборостроении и т. п.
Данная книга подробно рассказывает об особенностях разнообразного использования Agile, дает многочисленные примеры его применения за пределами ИТ-отрасли. Она не для айтишников. Им не надо ее читать. У книги конкретная аудитория – это все те, кто работает за пределами разработки программного обеспечения. Соответственно перестроен и язык, по возможности используется обычная (не айтишная) лексика. Фокус не только на Скраме, но и на всем Agile-мышлении и подходе. Знания сформированы разными практиками (в том числе практикой автора) и многочисленными источниками. Цитируется много фактов и примеров, даны аккуратные ссылки. Все, что описано, можно немедленно применять на практике, также по Agile, мелкими итерациями, анализируя эффекты и проводя корректировки. Надо просто пробовать.
Главы книги оформлены в спринты, в начале каждой главы – кратко о тех ценностях, которые эти спринты дают. Оглавление выглядит как план спринтов. Изучение книги превращается в движение по спринтам с наращиванием ценности в виде знаний. Представлены основные зоны интереса в Agile (по мнению автора), читать можно с любого раздела, а также возвращаться.
В книге 15 рисунков и более 100 примеров. Интернет-ссылки даны прямо в тексте – это поможет тем, кто будет использовать электронную версию, тут же изучить материал, не набирая ссылку вручную. В тексте всей книги термины Agile и Lean даются на английском языке. Scrum и Kanban, если они упоминаются отдельно, русифицированы как Скрам и Канбан. Это вызвано уже сложившейся практикой в России. В комбинации с другими терминами или практиками сохранены англоязычные написания.
В книге четыре приложения, включающие пример Agile-договора, чек-лист для выбора жизненного цикла проекта, пример устава команды и короткий тест с вопросами, похожими на те, которые дают при сертификации ACP.
Успехов вам в постижении Agile, дорогие читатели!
С уважением, В. Н. Фунтов, доктор экономических наук, PMP. Санкт-Петербургский международный институт менеджмента. Санкт-Петербург, 2019
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства 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 тесно связан с лидерством. Руководитель проекта работает с клиентами, специалистами и участниками проекта, чтобы обеспечить их осведомленность о статусе проекта и исключить все барьеры в нем.
♦ Фокус на бизнесе. Оценка приоритетов на основе значимости в бизнесе позволяет не допустить чрезмерного углубления команды только в разработку нового продукта. Если это произойдет, то проект может превысить запланированные затраты и стоить больше своей ценности.
♦ Усвоение полученных уроков. После каждой итерации команда оценивает все полученные навыки и знания для того, чтобы улучшить процесс на следующей итерации. Обучаясь, участники адаптируются к деятельности других коллег и работают вместе над улучшением производительности команды.
Bepul matn qismi tugad.
