Введение
Одна из главных причин неудач в реализации проектов – их разработка в отрыве от реального мира и бизнес-нужд. Существует много причин, почему это может произойти, но это всегда приводит к одному результату – недовольству заказчика и конечного пользователя. Для Agile главное – не допускать этого. Вся суть Agile строится на сотрудничестве и участии. Заказчики вовлечены в разработку на каждом этапе и участвуют в каждом принимаемом решении. Многие техники управления проектами отмечают, что это очень важно для разработки, но только гибкие подходы делают участие заказчика в процессе создания продукта обязательным. Это одно из ключевых отличий Agile. Получение первоначальной поддержки и заинтересованность в запуске проекта в гибкой разработке – очень важный момент, но постоянное участие в процессе – важнейшая составляющая успеха. После принятия гибких подходов на вооружение они вполне способны позаботиться о себе сами, органично развиваясь вместе с коллективом; но, чтобы создать условия, в которых это возможно, придется потрудиться.
Необязательно начинать с чего-то грандиозного – первый шаг может быть малым. Но для надежного старта необходимо завоевать сердца и умы правильных людей. Понимание того, чего хотят люди в компании, какие у них есть проблемы и как гибкие подходы могут им помочь, – важная часть процесса. Цель – это не изолированный эксперимент с Agile, даже если речь идет об одном блестяще проведенном проекте, а внутреннее гибкое преобразование всей организации. Это вполне достижимо, но для этого потребуется помощь и поддержка. Чем больше людей будут осознавать преимущества Agile, тем лучше. Важная составляющая стратегии принятия гибкости – убеждение ключевых игроков в ее необходимости. Что же может предложить им Agile?
Очень многое!
Причины перехода на Agile
Есть множество личных причин, по которым можно заинтересоваться гибкими подходами – от желания найти лучший подход к работе и до корыстных интересов. Некоторые выступают в крестовый поход с целью преобразить мир бизнеса, другие просто видят в этом отличный карьерный ход. На самом деле личные мотивы тут не имеют значения – всё равно все останутся в выигрыше.
Над личными целями здесь куда более практичные корпоративные стремления для принятия Agile. Они не столь расплывчаты: это увеличение количества довольных заказчиков, вывод организации на мировой уровень или создание инновационного окружения – цели, которые являются конкретными и измеримыми. Бизнесмены от внедрения гибкости ожидают умных, или, точнее, SMART-целей.
Главный аргумент, убеждающий всех сомневающихся, – это то, что гибкие подходы дают результаты в течение нескольких месяцев, чаще недель, и все, от руководства до команды, действительно заняты делом.
Мудрый способ побудить человека что-то сделать – заставить его поверить, что это была его идея.Нельсон Мандела
БЛИСТАТЕЛЬНое определение
SMART-цель – это
S – specific: конкретная; significant: значительная; stretching: растягиваемая.
M – measurable: измеримая; meaningful: полная определенного смысла; motivational: мотивирующая.
A – agreed upon: согласованная; attainable, achievable: достижимая; acceptable: принятая; action-oriented: ориентированная на действия.
R – realistic: реалистичная; relevant: релевантная; reasonable: приемлемая; rewarding: полезная; results-oriented: ориентированная на результаты.
T – time-based, time-bound, timely: ограниченная во времени; tangible: осязаемая; trackable: отслеживаемая.
Десять Smart-целей Agile
1. Продукты, отвечающие требованиям. Начиная с MVP и постепенно его развивая, вы даете заказчикам возможность видеть последовательное формирование продукта и изменить что-то, если это необходимо. Это обеспечивает наилучший результат и выпуск качественного продукта.
2. Сокращение времени выпуска продукта. Больше никакого бесконечного ожидания вплоть до истечения всех возможных сроков. MVP – уже работающий продукт, который выпускается скоро, а дополнения к которому выходят часто.
3. Ранняя окупаемость инвестиций (return on investment, ROI). Продукт выпускается быстро, что позволяет реализовать преимущества на раннем этапе разработки. Продукт начинает окупаться уже на этом этапе и продолжит с дальнейшим развитием. Таким образом, прибыль может быть получена быстрее.
4. Гибкость. Изменения – постоянная часть жизни. Вместо того чтобы плыть против течения, Agile принимает и даже поощряет перемены. Это намного больше соответствует естественному ходу (деловой) жизни.
5. Уменьшение рисков. Начиная с малого и развивая продукт постепенно, мы значительно уменьшаем риски. В тех редких случаях, когда дела идут плохо, затраты на исправление проблемы будут невелики. При таком подходе возникающие проблемы незначительны и разрешаются не в пример проще.
6. Высокая прозрачность процесса. Agile обеспечивает отличную прозрачность хода работ для ключевых заинтересованных сторон в отношении как прогресса разработки, так и самого продукта. Непрерывное участие и сотрудничество помогают устранить бессистемный подход и необсуждаемые темы в разработке.
7. Большая эффективность. Постоянное улучшение – важная часть Agile. Широко известные техники для измерения производительности помогают командам отслеживать свой прогресс. Быстрее, дешевле, лучше – все это реализуется не за счет качества продукта.
8. Предсказуемость. Положительный результат в целом гарантирован: бизнес получает то, что он хочет. Результативность достигается в короткие сроки, что, в свою очередь, обеспечивает нужный настрой. Успех приносит уверенность и приводит к большему успеху – такой позитивный замкнутый круг.
9. Удовлетворенные заказчики. Какие бы критерии ни применялись для оценки удовлетворенности, стоит ожидать необходимости добавления улучшений уже на раннем этапе. Гибкие подходы делают этот процесс проще. Любые негативные отзывы – лакмусовая бумажка для вашей работы.
10. Лучший настрой. Последнее в списке, но не по значимости. Довольный бизнес, счастливая команда – все это означает здоровое рабочее пространство и вырабатывает привычку к успеху, где нормой становятся успешные, а не провальные проекты.
Влияние на влиятельных
Даже если в текущих проектах организации царит полный хаос и множество проблем, сейчас нельзя никого заставить разрешать эти неприятности именно с помощью Agile. В большинстве случаев все не совсем ужасно, а просто плохо, и с помощью Agile нужно просто немного помочь получить первый важный шанс показать, на что способны гибкие подходы. Иногда получение такой возможности не является большой проблемой – особенно в небольших организациях, но в целом Agile может быть не единственным кандидатом.
– Денег нет, но вы держитесь. (А моя зарплата неприкосновенна.)
Крайне важно получить поддержку руководства для первого проекта. Нет необходимости настаивать на полномасштабном преобразовании – гибкость вполне может быть применена в малом проекте. Сама суть Agile – определить MVP и развивать его постепенно, и в этом смысле одного проекта более чем достаточно. Даже если вам предложат большой проект с самого старта, работайте по той же схеме: начинайте сначала с малого, а затем наращивайте скорость.
Может быть, у вас есть возможность решать, как именно будет структурирован ваш следующий проект. Замечательно, если так. Не всегда, но довольно часто достаточно согласия одного человека. Быть может, вам нужно убедить человека, ответственного за выполнение проектов, например официального руководителя всей программы, у которого постоянно несколько текущих проектов. Даже в больших компаниях будет кто-то с достаточным влиянием, чтобы принять решение. Если все остальное терпит неудачу, рискните и постучите в дверь генерального директора или ближайшего доступного старшего менеджера.
Блистательная мысль
Есть только три ключевых фактора успеха для запуска любого Agile-проекта:
• выбор подходящего проекта;
• заинтересованность представителя бизнеса в активном участии;
• участие людей с гибким мышлением.
Даже если вам и придется дойти до генерального директора, суть не поменяется и не сможет быть изложена за несколько минут. Вооружитесь нашими десятью SMART-целями для гибких подходов, чтобы изложить, что можно достичь. Выберите подходящий для начала проект – и вероятность того, что вы получите одобрение, будет очень высока.
Четыре способа все испортить
• Заявите, что Agile – единственный вариант.
• Объявите, что все настолько очевидно, что любой дурак сможет справиться и не потребуется никакого обучения.
• Скажите, что гибкие подходы безошибочны, а причина неудач – недостатки отдельных людей.
• Выберите невыполнимые сроки и цели, заявив, что в дивном новом мире Agile нет ничего невозможного.
Agile в массы!
Даже до того, как вы возьметесь за продвижение идеи попробовать гибкие подходы в действии, начинать вы будете не с нуля – почти каждый что-то да слышал про Agile, и большая часть этого услышанного весьма положительна. Сама идея не нова, но в последние годы переживает очередной всплеск интереса – так что сейчас, на этой волне популярности, самое время предлагать ее испробовать. В некоторых кругах даже считается неприличным предполагать, что гибкие решения – не наилучший вариант.
Неофициальный пиар Agile работает так же и может помочь и вам. Есть целый ряд организаций, страстно приверженных Agile, так почему бы не упомянуть несколько названий? Как насчет Intel? Spotify? Google? Старых добрых Waitrose? Сейчас сложнее будет найти организацию, которая не заинтересована в поиске новых способов улучшения производительности. Ну а Agile у себя внедряют хорошие компании.
Убедитесь в том, что ваши попытки по внедрению гибких подходов воспринимаются всерьез. Определенное недоверие относительно успешной реализации многообещающих перспектив Agile вполне естественно, но никто в здравом уме не будет отказываться от этих перспектив, если они подтверждены на практике; а если это все-таки происходит, возможно, вам стоит поискать другую работу. Скорее всего, вам дадут зеленый свет, а в худшем случае попросят рассказать больше об Agile. Вероятность полного отказа весьма незначительна.
В крайнем случае не бойтесь пустить в ход знаменитый девиз Agile: быстрее, дешевле, лучше. Возможно, вам понадобится объяснить, как вы собираетесь этого добиться, однако звучит он просто превосходно.
Предзапуск Agile для начинающих
Используйте запуск нового проекта как повод, чтобы рассказать о гибких подходах. Пусть заинтересованные стороны знают, чего ожидать и что именно будет по-другому, особенно когда это первый проект такого рода. Несколько часов, проведенных за объяснением основ Agile, улучшат понимание и будут способствовать принятию.
Это так называемый образовательный пиар, и он исключительно важен перед началом проекта.
Если вы пытаетесь убедить людей что-то сделать или купить, вы должны использовать тот язык, на котором они говорят и думают каждый день.Дэвид Огилви
Не только для IT
Одно из самых распространенных заблуждений заключается в том, что Agile подходит только для проектов в области информационных технологий (IT). В действительности это далеко не так, и большая часть концепций, с которыми вы можете ознакомиться в этой книге, отлично подходит и для других сфер деятельности. Одним из основных исключений является экстремальное программирование (XP, eXtreme Programming), что, впрочем, неудивительно, учитывая название. Автоиндустрия в этом плане является лидирующей с их технологией бережливого производства, а практика показывает, что IT в этом плане несколько более консервативны. Нет никаких сомнений в том, что масса IT-команд использует гибкие подходы. Их опыт был бесценен для их совершенствования, но это не означает, что IT имеет эксклюзивное право на применение Agile.
Помимо этого следует упомянуть распространенное убеждение, что некоторые отделы внутри крупных организаций менее предрасположены к Agile, но это совершенно не означает, что эти отделы ни при каких обстоятельствах не перейдут на гибкую сторону. Отдел финансов – один из типичных примеров отделов, которым нелегко свыкнуться с мыслью о гибкости, но если поискать, то вы без труда найдете массу примеров, когда отделы финансов используют ее исключительно продуктивно. Более того, использование гибкого подхода к финансам является ключевым залогом успеха гибкого проекта, так как попытки реализации гибкого проекта с фиксированным бюджетом, результатами и расписанием и полным отсутствием гибкости обречены на провал.
При этом нет никаких сомнений в том, что легче всего начать путешествие в мир Agile с наиболее легкого варианта. IT-проекты, безусловно, не являются единственным вариантом, но это одна из самых доступных возможностей.
Блистательный пример
Прежде чем перейти к реализации проекта, следует обговорить фундаментальные культурные условия, необходимые для реализации гибких принципов и гибкого мышления. Без гибкой атмосферы проект неизбежно зачахнет или же вернется к старым и исключительно негибким подходам. Ниже представлены условия, необходимые для успешной реализации Agile в проекте:
• принятие гибкой философии перед началом проекта – включая сегментированный подход, сотрудничество и все итерации разработки;
• принятие решений внутри команды – расширение полномочий участников команды;
• заинтересованность представителя заказчика в постоянном участии в проекте – гарантированный доступ к нужному ресурсу;
• согласие на инкрементную поставку – принятие того, что это желаемый и практичный вариант;
• постоянный доступ ко всем участникам команды – предпочтительно работающим на доступном расстоянии друг от друга или при налаженной системе связи;
• постоянный состав команды – на протяжении всей работы над проектом;
• правильно подобранные специалисты с гибким мышлением – команда профессионалов с коммуникативными навыками;
• необходимый размер – маленькая команда для обеспечения наилучшего взаимодействия и сотрудничества;
• благоприятная коммерческая база – сначала доверие и сотрудничество, а потом уже любые оговорки.
Важно помнить, что нельзя быть гибким только на словах. Достаточно легко согласиться с идеями Agile в теории, но переход от теории к практике в данном случае вряд ли дастся легко. Довольно бессмысленно с практической точки зрения назначать младшего менеджера в качестве бизнес-представителя, а затем заставлять его обращаться за подтверждением к начальству перед тем, как принимать любое решение. Аналогично нет никакого смысла в том, чтобы передавать полномочия команде, а затем заставлять их обращаться за разрешениями к вышестоящему руководству. Чтобы подходы Agile работали успешно, необходимо, чтобы у участников команды слова не расходились с делом.
Оценка успешности
Упоминание показателей эффективности работы обычно имеет негативный эмоциональный окрас. Было время, когда простое упоминание этого термина вызывало в памяти образ надзирателя с секундомером, заносящего в блокнот результаты производительности. Давно уже было высказано утверждение: если вы не можете что-то измерить, оно не может быть улучшено – но убедить в этом большинство людей почти невозможно. Суть в том, что показатели эффективности всегда были инструментом руководителей для того, чтобы выжать как можно больше из сотрудников.
Гибкая революция в реализации метрик показателей эффективности и тут перевернула все с ног на голову. Любые характеристики принадлежат команде и используются ими для выполнения работы. Из-за этого сдвига акцентов показатели эффективности лучше воспринимаются, поскольку команды могут теперь посмотреть, как именно идет работа. Без этих характеристик гибкие подходы – особенно Скрам и Канбан – не смогут функционировать должным образом.
Характеристики в Agile по-прежнему чрезвычайно полезны для организации, но они больше не рассматриваются как инструмент контроля работников.
Блистательное определение
Основные принципы 1–2-3 для определения метрик показателей эффективности:
• определите важнейшие процессы или требования заказчика;
• определите специфический, измеримый результат работы;
• установите цели, по которым можно измерить результаты.
Мантра любых метрик: измерь, проверь и улучши. Без измерения ничего не выйдет.
Если команда управляет всеми метриками, это говорит о том, что они намного надежнее и имеют большое значение для компании. Это особенно заметно при измерении скорости работы (характеристика Agile-команды), где команда рассчитывает свою скорость выпуска продукта и использует эту информацию для прогнозирования работы в заданных временных ограничениях. Такой прогноз намного надежнее, потому что он основан на прошлом опыте. Члены команды довольны выбранными задачами, потому что они не навязаны им, а бизнесмены заранее имеют представление о том, что они получат за свои деньги.
Поскольку гибкие подходы сосредоточены на бизнес-ценности, показатели всегда должны быть понятными для заинтересованных сторон. Процесс расчета выполняется для команды, и значение скорости будет разниться, однако конечный результат вполне точен. Это субъективное значение может быть использовано для вычисления того, что именно и через какое время может быть выпущено. Например, «Agile-команда A реализует функции A, B и C через X недель». Заказчик точно знает, чем занята команда в этот период времени и на что именно уходят его денежки.
Блистательный пример
Краткое пособие по использованию скорости работы команды в Agile.
• Согласуйте шкалу от одного до пяти для измерения масштабов работы (например, 1 = незначительная, 5 = большая).
• Оцените по этой шкале все задачи, которые должна выполнить команда в определенный временной промежуток (например, две недели).
• Сосчитайте общее количество баллов реализованных задач (скорость работы команды).
• Определите минимальные и максимальные значения, чтобы определить предельные значения скорости для команды.
• Исключите самое большое и самое маленькое значение и высчитайте среднее значение для оставшихся (общее количество баллов реализованных задач, поделенное на общее количество временных промежутков).
• Планируйте выполнение будущих задач на основе средней скорости. Повторяйте до тех пор, пока запланированное и фактическое значения скоростей не будут совпадать.
Вы можете использовать это значение для прогнозирования выполнения задач.
Двоякая польза отчетов
Плохую коммуникацию обычно называют одной из главных причин неудачных проектов. В традиционных методах управления была замечена тенденция к тому, чтобы в начале любого начинания руководители были чрезмерно оптимистичны, а затем игнорировали проблемы, появляющиеся во время работы до тех пор, пока не становилось слишком поздно. Это создает неопределенность в отношении реального состояния дел, а иногда и плохое предчувствие с самого начала. Плохо, когда единственная обратная связь по прогрессу работ осуществляется через нерегулярные, неясные отчеты.
И здесь гибкие подходы все меняют. Представителям заказчика не нужно постоянно спрашивать о прогрессе, потому что они полностью вовлечены в процесс. Вместо того чтобы тратить время на отслеживание хода работы, бизнес может сосредоточиться на более важных вещах. Время тратится на более полезную деятельность.
Даже если люди, непосредственно вовлеченные в разработку, точно знают, как обстоят дела, все равно необходимо доносить информацию и до оставшейся части компании. Например, использование статусов по цветам светофора (RAG: Red, Amber, Green. Красный, желтый, зеленый) резко отличает Agile от традиционных методов управления, в которых людям, не участвующим в проекте, используемые метрики обычно непонятны. От Agile-команды ожидается, что она будет представлять плоды своих трудов в формате бизнес-ценности, по которому можно будет сделать прогноз о будущей производительности.
Блистательное определение
Доклады о ходе работы обычно используют систему цветов светофора или «RAG-статус» как визуальный сигнал для суммирования производительности для всех заинтересованных лиц:
Красный – серьезные проблемы, блокирующие дальнейшую разработку.
Желтый, или янтарный, – препятствия, которые могут быть устранены.
Зеленый – все в порядке.
Гибкие отчеты по проекту – это регулярные новости, обновляющиеся каждые несколько недель. Они полностью сосредоточены на том, что было выпущено или что скоро планируется выпустить, – настоящие новости, которые понятны организации и в которых нет места отговоркам и попыткам что-то скрыть.
Блистательный пример
Полезным инструментом для отслеживания прогресса является диаграмма сжигания задач. Она показывает прогресс выполнения проекта в наиболее распространенном варианте в виде двух линий на графике:
• общая работа – суммарная оценка сложности проекта – в динамике;
• выполненные задачи – в динамике.
Она очень отличается от диаграммы сгорания задач. График показывает общую работу по проекту (обычно в условных баллах) в сравнении с выполненной работой в течение определенного периода времени. Это визуальное отображение прогресса работы над проектом, отслеживающее выпуск продукта и оставшуюся работу.
На графике ниже пунктирной линией показано общее количество баллов по пользовательским историям, которые команда должна завершить в течение восьминедельного спринта, чтобы обеспечить быстрый и качественный выпуск продукта. Линия из точек отображает суммарное количество задач, выполненное командой.
Рис. 7.1. Блистательная диаграмма сжигания задач
На графике видно, что после несколько неуверенного старта команда вышла на постоянную скорость работы, однако владелец продукта постоянно добавлял новые задачи. Можно сделать вывод, что проект будет закончен вовремя, если в последние две недели не будут добавлены новые требования.
Избегайте повторения ошибок
В конце концов, Agile не обеспечивает полную защиту от типичных ловушек, так что будьте человеком широких взглядов и учитесь на трудном опыте других, будь они приверженцами Agile или нет. В некоторых кругах есть тенденция пренебрегать старой школой, но там есть что почерпнуть, особенно в отношении их наиболее распространенных оплошностей. Самые известные проблемы уже исправлены самой гибкой философией, но не обманывайтесь предположением, что она способна защитить вас от всего.
В разгар битвы за внедрение Agile важно сохранять реалистичность при предоставлении гарантий насчет «что» и «как». Не увлекайтесь идеей быстрее, дешевле, лучше. Будьте особенно осторожны в чрезмерно оптимистичных оценках преимущества внедрения Agile и не игнорируйте минусы. Блестящие результаты не нужны, если очень хороших более чем достаточно. Если вы ожидаете идеального результата, даже оценка 9 из 10 может разочаровать.
Будьте осторожны с людьми, которые не поняли все аспекты работы в Agile. Для СЕО возникает соблазн не слышать ничего за пределами прекрасной картины быстрее, дешевле, лучше. Или просто настроиться на обещания работающих продуктов, скорейшего выхода на рынок, ранней окупаемости инвестиций, гибкости, меньшего риска, большей эффективности, довольных заказчиков, а совершенствование культуры и изменение настроя компании попросту проигнорировать. Не предполагайте, что все читают в договоре использования условия, напечатанные мелким шрифтом, – никто этого не делает.
Блистательная мысль
Стандартные ошибки могут объявиться и в мире Agile. Не берите с собой в новый мир старые проблемы. Нет ничего более грустного, когда ваши коллеги думают: ну вот, опять. Предупрежден – значит вооружен!
• Нечеткие цели и задачи – начинайте всегда с понятным видением проекта.
• Неопределенные требования заказчика – пользовательские истории должны быть ясными.
• Недостаточное обучение – обеспечьте соответствующие тренировки и коучинг.
• Нереалистичные цели – даже гибкие подходы ничего не смогут сделать с навязанными извне невыполнимыми сроками.
• Пренебрежение ресурсами – позвольте команде решать, какие цели можно будет выполнить.
• Повторение ошибок – смертный грех любых решений; всегда проверяйте и приспосабливайтесь.
Невозможно сыграть симфонию в одиночку. Для этого нужен целый оркестр.Хэлфорлд Лаккок (американский методист, министр и профессор)
Завершающие слова
Обычно разработчики проектов считают легким планирование задач так, как если бы проект находился в вакууме – и иногда это даже кажется распространенной нормой. Однако такой подход приводит к тому, что проект оказывается оторван от реального положения вещей. Agile исповедует другую философию и основывается на сотрудничестве и взаимодействии. Как минимум гибкие подходы гарантируют активное участие заказчика в проекте, но в идеале они подразумевают также вовлеченность всей организации, к которой разработчики принадлежат, особенно если в дальнейшем вы собираетесь фактически использовать Agile как основные решения для будущих проектов.
Agile-проекты по определению будут более прозрачными и наглядными – в конце концов, это одна из целей гибких подходов. Очень поможет, если суть и принципы Agile будут понятны всем, кто вовлечен в процесс, – даже таким отделам, как финансы и маркетинг, которые в традиционных методологиях обычно игнорируются. Открытость в основах гибких решений приводит к тому, что о них узнают и другие люди, так что вполне можно ожидать повышенного интереса. Не удивляйтесь, если генеральный директор или финансовый директор придут на презентацию. Наоборот, стоит опечалиться, если этого не произойдет.
Нет необходимости вовлекать вообще всех, это не крестовый поход. Но обращайте внимание и на не столь очевидных кандидатов.
Блистательный итог
• Ознакомьтесь с причинами, которые могут заинтересовать всех принимающих решения насчет введения Agile, – с каждым нужно говорить на его языке.
• Agile – больше чем термин из IT; не оставляйте без внимания ни один аспект.
• Отчеты, фокусирующиеся на выпуске продукта и конкретных достижениях, – это именно то, чего все хотят.
• Даже «старая школа» может пригодиться; она уже давно столкнулась с большинством проблем.
• Не переоценивайте себя; даже блестящий результат может разочаровать, если настроиться на идеальный.