Страница 3 из 6
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, отправляя человека на Луну, управление было, наверное, самой сложной задачей.
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: процессы, кейсы, проекты
Операционный менеджмент – это освещение тоннеля, стратегический менеджмент обеспечивает наличие света в конце тоннеля, а проектный менеджмент – это двигатель поезда, который и движет организацию вперед.
Agile и процессы
Процессы в компании – это обычно повторяющиеся действия, исполнение типовых должностных инструкций, регламентов или процедур, типовые ситуации с низкой неопределенностью и постоянными участниками. Примерами процессного менеджмента как способа организации однородного труда являются, например, серийное и типовое производство, обслуживание, банковские услуги, регулярные продажи и т. п. Agile, фокусирующийся на гибкости и снижении потерь, для повышения эффективности рутинных процессов может предложить, например, следующее:
1
http://www.milresource.ru/Boyd.html
2
Кон также написал очень хорошие книги, такие как «Agile: Оценка и планирование проектов», «Scrum. Гибкая разработка ПО», «Пользовательские истории. Гибкая разработка ПО» (см. список литературы).