Записаться

Десятая глава является завершающей главой данного курса.

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

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

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

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

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

Одна из наиболее авторитетных организаций в области процессов SEI (организация - автор модели CMMI) опубликовала технические заметки, в которых излагается, почему можно использовать оба метода одновременно.

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

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

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

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

Нет процесса, который одинаково эффективен при различных условиях функционирования.

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

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

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

10.2. Обеспечение соответствия лучшим практикам и стандартам

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

По сути это означает, что разработчики программного обеспечения должны использовать сходный набор передовых методов и применять в практике создания программных продуктов такие стандарты, как ISO 9001 (процессные стандарты), ISO 13458 (стандарт медицинской отрасли), требования закона Сарбейниса-Оксли (акционерные компании на территории США) и пр. Таким образом, одной из задач Scrum-команды, направленной на разработку качественного программного продукта, является постоянная забота о том, как интегрировать профильные стандарты в создаваемый ими продукт.

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

Членам Scrum-команд необходимо заботиться о том, чтобы соблюсти набор правил и принципов, предписываемый "best practice" и профильным стандартам. Для этого следует:

• Организовать процесс документирования требований к продукту в согласованном командой формате. Система документирования требований позволит описать набор автоматизированных функций и иметь постоянный доступ к площадке оперативного обсуждения последующих доработок и развития функционала продукта в соответствии с актуальными требованиями бизнеса.
• Создать базу знаний команды/продукта. База знаний команды/продукта - это своего рода интеллектуальный компонент команды, который позволяет организовать процессы решения возникающих проблем путем документирования в различных форматах (руководства, описания, статьи и т. д.) наиболее важной информации. Базы знаний позволяют накапливать информацию и преобразовывать ее в соответствии с актуальными нуждами команды. Основное назначение - оказать помощь наименее опытным сотрудникам при решении определенных проблем.
• Управлять изменениями. О важности процесса управления изменениями было сказано в предыдущих главах. Здесь же еще раз укажем на то, что управлять изменениями нужно на постоянной основе не только в разрезе разработки продукта, но и в разрезе организации "гибких" процессов, оптимальным образом адаптируя их под нужды организации.
• Документировать актуальное состояние процессов в команде. Для того чтобы на постоянной основе заниматься развитием и совершенствованием процессов по передовым практикам и стандартам, необходимо иметь актуальное состояние процессов задокументированным. Только тогда будет возможность оперативно рассмотреть их и принять управленческие решения.
• Применять передовые технологии для автоматизации процессов (тестирование, сбор требований и т. д.). Члены команды, используя процедуры ретроспективы или механизмы самоанализа выполняемой ими работы, должны постоянно задумываться над используемыми ими техниками, инструментами, профессиональными привычками. Наиболее "отсталые" из них, те, эффективность которых низкая, необходимо модифицировать в соответствии с актуальными условиями Scrum, повышая их ценность и значимость, или же отказываться от них в пользу новых. Описанное так же верно и для автоматизации процессов тестирования, работы с требованиями и пр.
• Искать, тестировать и использовать инновационные инструменты, которые оптимизируют вашу деятельность. Члены команды должны постоянно находиться в технологическом поиске. Качество постоянного несогласия с факторами, влияние которых негативно отражается как на командной, так и на личной работе, - отличное качество разработчика. Разработчик может, а порой и должен смириться с недостатками конкретной ситуации, но при этом ему следует постоянно искать пути решения системных проблем. Он должен постоянно искать, пробовать, изменяться, предлагать удачные и отказываться от неудобных рабочих инструментов. Это, по сути, и есть Agile.
• Приглашать профессиональных аудиторов. Роль аудитора в реалиях Agile не нужно недооценивать. У команды, как правило, всегда все хорошо. Недостатки и несовершенства могут "замыливаться" за операционной деятельностью коллектива. Человеческая натура так устроена, что она постепенно привыкает ко всему. К хорошему быстро, к плохому чуть медленнее. Аудитор - сотрудник, который должен непредвзято провести валидацию процессов. С помощью его отчетов можно объективно сопоставить, как у команды получается двигаться в желаемом направлении развития, выделить наиболее слабые места, на работе которых стоит сделать акцент. Аудитор может быть как внешний, так и внутренний, главное в его работе - видеть процесс и роли, а не ситуацию и отдельных личностей.
• Приглашать квалифицированных консультантов. "Вариться в собственном соку" очень важно. "Не вариться" сопоставимо с "не развиваться". В силу того что члены команды не всегда знают, как наиболее оптимально решать возникающие проблемы и чем принятые решения могут "грозить" в дальнейшем, важно привлекать консультантов, которые обладают практическим опытом решения проблем, с которыми столкнулась или может столкнуться команда. Перед тем как их приглашать, следует убедиться в том, что консультант сможет помочь, а не придет "отсидеть" свою стоимость.

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

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

10.3. Использование Lean-методологии в Scrum-процессе

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

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

В Lean, так же как и в Scrum, работа разбивается на небольшие пакеты (сравнимо с понятием бэклога спринта), которые должны реализовываться отдельно и независимо. Lean, в целях разработки предсказуемого результата, содержит определенный поток операций (workflow) с этапами. В Scrum существуют свои специфичные процессы и процедуры, которые подтвердили свою эффективность. Lean добавляет к "гибким" принципам схему потока операций, для того чтобы каждая из итераций выполнялась одинаково качественно.

Оба направления в своей основе имеют системный подход, основанный на постоянном обучении и совершенствовании. В данном случае Scrum является базисом, на основе которого станет возможным "надстраивать" специфичные методы и методики, которые будут способствовать повышению эффективности процессов компании и, как следствие, увеличивать/улучшать результат.

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

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

Lean позволяет параллельно выполнять несколько задач на разных этапах, что повышает гибкость и увеличивает скорость исполнения проектов.

Как и гибкие процессы, Lean более похожа на концепцию, образ мышления, нежели четко регламентированную методологию. Используя принципы Lean, можно создать адаптивную систему, удовлетворяющую конкретным требованиям. Для этого необходимо следовать следующим принципам:

• Постоянно определять ценность конкретного продукта. Разработчик должен исследовать реализуемый продукт и наблюдать за ним. Более того, по мере функционирования команды и разработки зрелого продукта каждый разработчик должен научиться оценивать то, какими параметрами необходимо обладать, чтобы стать ценностью.
• Определить и контролировать поток создания ценности. Поток создания ценности - это последовательность действий, совершаемая для преобразования исходного материала в конечный продукт, приносящий ценность. Если конкретный этап не создает ценности, целесообразно провести его изменение или удаление из процесса.
• Обеспечить непрерывность потока создания ценности. Вместо дискретной организации перемещения продукта по стадиям процесса необходимо рассмотреть возможность создания потока, в котором происходит непрерывное движение продукта по стадиям через специализированные точки (вехи), в которых будет возможность организовать операционный контроль как стадии, так и качества продукта путем измерения заранее разработанных метрик.
• Позволить пользователю/владельцу продукта "вытягивать" продукт. Пользователи, находящиеся "выше" по процессу, ничего не должны делать до тех пор, пока конечный потребитель, расположенный "ниже", этого не потребует. Должны создаваться все условия для того, чтобы потребитель "вытягивал" продукт, то есть производство продукта осуществлялось под конкретный заказ. Таким образом, именно конечный пользователь будет запускать "вытягивание" по всем этапам производства.
• Постоянно стремиться к развитию и совершенству. Разработку продукта в Lean можно совершенствовать бесконечно, максимально приближая его к "идеалам" ожиданий заказчика. Можно сколь угодно уменьшать трудозатраты, время на разработку и пр.

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

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

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

10.4. Продуктивность Scrum для цифровой трансформации

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

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

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

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

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

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

• Фокус на "понимании" клиентов. Результат от внедрения цифровой трансформации, как правило, начинается с плодов выделения основных категорий клиентов компании в тех или иных регионах и рыночных сегментах. Большинство компаний обращается к социальным сетям, чтобы понять предпочтения клиентов и их основные потребительские ценности.
• Реклама через социальные медиа. Компании учатся быть более эффективными в социальных сетях и прочих медиа. Для этих целей создаются сообщества, чтобы консультировать клиентов и формировать у них лояльность.
• Акцент на измеримых результатах. Предприятия используют инструментарий аналитических систем для более подробного изучения своих явных и потенциальных клиентов, изучения их поведенческих моделей и пр. Проводимые эксперименты позволяют динамически регулировать цены на продукцию в зависимости от спроса и других условий.
• Трансформация точек контактов с клиентами. Качество предоставляемых клиентам продуктов/сервисов/услуг будет повышаться за счет инноваций по использованию цифровых технологий. К примеру, стали создавать аккаунты в социальных сетях для приема жалоб. Этот подход позволяет оперативно решать вопросы, привлекать различные сообщества для решения разнообразных задач. Кроме того, компании, использующие мультиканальное обслуживание, испытывают затруднения при обеспечении комплексной поддержки каналов. Переход к омниканальности (единому каналу общения) поможет оптимизировать затраты и сконцентрировать компетенции и опыт на наиболее критичном виде услуг.
• Преобразование операционных процессов. Цифровая трансформация - один из наиболее интересных и сложных процессов преобразования компании, но при этом он, как правило, приводит к необходимости трансформации связанных с ним внутренних процессов.
• Рост выручки. Компании заинтересованы в цифровой трансформации и технологиях для того, чтобы повысить свою выручку, аккумулируют информацию о клиентах для обеспечения более точных продаж и персонализированного обслуживания. Таким образом, компания может в режиме реального времени отслеживать реакцию на свои продукты, что поможет в дальнейшем корректировать взаимоотношения с клиентами.

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

10.5. Современная критика Agile

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

Если вам заявляют, что стоит пригласить внешнего Agile coach или Scrum-мастера и они смогут выполнить всю необходимую работу, то это тоже неправда. Сегодня на рынке есть множество компаний, которые не программировали и не имеют опыта руководства людьми. Подобное "обучение" с помощью таких специалистов не принесет значимых плодов. Люди, занимающиеся пропагандированием и внедрением гибких практик, должны уметь программировать, анализировать, руководить, тестировать и обладать в этих навыках достаточно высоким уровнем компетенции. Если подобного опыта у "всезнающего" консультанта нет, то как с ним можно обсуждать специфические ситуации, связанные с продуктом или Scrum? Консультант по внедрению гибких процессов, который получил высшее образование вчера и не написал ни строчки кода, приносит меньше пользы, чем члены команды. Нельзя обучать тому, чего ты ни разу не делал. И "делать" означает "делать многократно и постоянно", а не иметь в послужном списке один пилотный проект.

При этом найти причины неудач очень просто. Их и искать не надо - они, как правило, лежат на поверхности. Принципы Scrum предписывают, как нужно действовать, но в них не описан алгоритм работы. Эта концептуальность критикуется, но, если бы гибкие методологии претендовали на роль конкретных техник, тогда их использование не нашло бы такого широкого распространения. Алгоритм работы должен быть определен в конкретной организации с учетом условий ее деятельности и его поэтапной корректировки в целях совершенствования. Гибкие методологии не должны навязываться. Они должны быть добровольно приняты и одобрены коллективом разработчиков, которые заинтересованы в его применении. Попытка навязать его применение приведет к подавлению роли команды и последующему отторжению.

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

• Догматичность. Agile предполагает адаптивный, гибкий и креативный framework, который рождает фанатиков, "повернутых" на его использовании. Без профессионального запала сложно постоянно совершенствовать любую методологию, но чрезмерное увлечение ею отпугивает потенциальных пользователей.
• Сектантство. Не стоит замыкаться на Scrum, следует обращать внимание и на другие подходы к разработке.
• Доминирование консультантов. Преобладание бывших "гуру", которые стали теоретиками и оторваны от реальной практики работы.
• Люди. Расчет на жесткую самодисциплину. Психологическое, эмоциональное, профессиональное выгорание членов команды. Зависимость от слаженной командной работы. Зависимость от ресурсов команды и отдельных "лидерских" персоналий. Необходимость постоянного участия в команде компетентного руководства, заинтересованного в достижении высоких результатов.

Agile - очень требовательная культура. Меняться и гнуться предстоит всем.

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

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

10.6. Что дальше

Вряд ли можно рассчитывать на то, что гибкие методологии будут применяться в идеальной среде, свободной от вмешательства окружающего реального мира. Неидеальность реального мира - это реальный факт. Этот факт необходимо учитывать всегда. Таким образом, очевидна необходимость сопровождения и развития отдельно взятого Scrum конкретной компании. Scrum - гибкая процессная методология, или, по-другому, - управленческая дисциплина. И как любую дисциплину, цель которой - приносить предсказуемый результат, ее необходимо контролировать. Но трудоемкость менеджерских активностей можно уменьшить и с самого начала "воспитывать" в сотрудниках, входящих в Scrum-команду, лояльность к изменениям, приверженность к обучению и совершенствованию. Явным результатом этого будет достижение более высокого уровня процессной зрелости и профессиональной культуры.

Путем экспериментирования Scrum-команды могут повести организацию к освоению все более и более эффективных способов работы.