Итоги и перспективы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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