Реализация гибкой разработки в крупных организациях может оказаться очень сложной и трудоемкой задачей. Гибкие практики, которые можно масштабировать и направлять на решение неотложных задач предприятия, включая критически важные системы, - это много больше, чем просто утренние летучки и фиксированные по времени спринты. Для успеха организации необходимо, чтобы все проекты, в которых используются гибкие процессы, были в равной мере успешны с точки зрения производительности и качества. В статье рассматриваются ключевые факторы успешного внедрения практик гибкой разработки в организации. Также обсуждается внедрение надежных, проверенных временем (зрелых) гибких процессов.

О важности инструментов

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

У моей матери случился инфаркт, после которого ей в течение года требовался постоянный уход. Сначала мы переоборудовали нашу гостиную в послеоперационную палату, а затем приступили к сооружению пристройки к дому, чтобы у мамы было отдельное помещение с ванной комнатой для инвалидов. Очень скоро у меня на заднем дворе среди прочей специализированной техники появился даже бульдозер. Жизнь быстро напомнила, что квалифицированным работникам нужны соответствующие инструменты и процессы, чтобы выполнять свою работу наилучшим образом. Без качественных инструментов обойтись нельзя!

Зрелые гибкие процессы

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

Масштабируемость

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

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

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

Повторяемость

Управление жизненным циклом приложений (application lifecycle management - ALM) обеспечивает повторяемость благодаря поддержке SDLC (software delivery lifecycle) - полного жизненного цикла поставки ПО или систем. Зрелые гибкие практики являются повторяемыми, предсказуемыми и могут масштабироваться для поддержки групп требуемого размера. Зрелые гибкие процессы должны строго придерживаться ценностей и принципов гибкой разработки. Это очень важно, потому что очень часто встречаются проекты, где гибкая методология используется только на словах, оказываясь при ближайшем рассмотрении просто оправданием для кода без четко определенных требований. Я буду говорить о степени, в которой методология разработки придерживается практик гибкой разработки, как о чистоте гибких процессов.

Чистота гибких процессов

Гибкие процессы должны придерживаться ценностей Манифеста Agile. Вот эти ценности:

• Личности и взаимодействия важнее, чем процессы и инструменты.
• Работающее ПО важнее, чем исчерпывающая документация.
• Сотрудничество с заказчиком важнее, чем контрактные обязательства.
• Реакция на изменения важнее, чем следование плану.

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

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

ИТ-руководство

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

Это не означает, что высшее руководство должно принимать все решения. В зрелой среде гибкой разработки самоуправляемые группы также играют жизненно важную роль в принятии многих ключевых решений, но, в идеале, в момент, когда имеется вся необходимая информация. Многие энтузиасты гибкой/бережливой разработки называют это последним ответственным моментом (Last Responsible Moment) - решение откладывается до получения всех фактов, чтобы принимать его на основе самой актуальной информации.

Культура прозрачности

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

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

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

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

Планирование проекта

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

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

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

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

Планирование итераций и выпусков

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

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

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

Управление конфигурациями и гибкие практики

Управление конфигурациями (configuration management - CM) играет важную роль в контексте гибкой разработки. При зрелой гибкой разработке CM помогает разумно управлять исходным кодом, обеспечивая поддержку итоговых выпусков, автоматизированных независимых сборок и различных вариантов кода (например, исправлений ошибок).

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

Инжиниринг выпуска позволяет создать надежный пакет, включающий манифест с содержанием сборки, часто называемый спецификацией (BOM - bill of materials). Во многих средах создается защищенный пакет выпуска, облегчающий процедуру развертывания приложения.

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

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

Подобный уровень автоматизации способствует также быстрой итеративной разработке.

Быстрая итеративная разработка

Гибкая разработка требует множества итераций. В такой ситуации особое значение приобретает автоматизация сборки, упаковки и развертывания приложений. Многие группы при создании приложений используют непрерывную интеграцию (continuous integration - CI), часто по несколько раз в день. Бывает, что ночной сборки достаточно, но быстрая итеративная разработка показывает необходимость хорошо автоматизированного и повторяемого процесса сборки, упаковки и развертывания приложений, который в конечном итоге переводит готовый выпуск в среду тестирования, используя зрелую инфраструктуру развертывания.

Быстрая итеративная разработка требует внимания ко всему жизненному циклу разработки приложения. Кроме того, она требует уделять необходимое внимание качеству ПО, в том числе автоматизированным модульным тестам и анализу кода.

Такой широкий взгляд помогает поддерживать весь жизненный цикл разработки ПО и систем.

Полный жизненный цикл разработки ПО

Управление жизненным циклом приложений (application lifecycle management - ALM) является попыткой управлять всем жизненным циклом, поэтому инструменты, поддерживающие гибкое ALM, должны способствовать управлению всем жизненным циклом, - от планирования, сбора требований и проекта до сборки, упаковки и развертывания приложения. Все участники зрелой гибкой разработки знают стоящие перед ними ежедневные задачи.

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

Задачи и дефекты могут также иметь свои собственные структуры взаимосвязей.

Иерархия задач и дефектов

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

Еще одним аспектом зрелого гибкого процесса является сосуществование с негибкими процессами.

Сосуществование с негибкими процессами

Зрелая гибкая разработка ПО должна сосуществовать с негибкими процессами и обеспечивать поддержку ИТ-руководства и соответствия нормативным документам.

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

Современные инструменты должны поддерживать гибридные модели с гибкими и негибкими процессами разработки ПО. Наряду с гармоничным сосуществованием с негибкими методиками от гибких методик часто требуется следование отраслевым стандартам и условиям.

Гармонизация с отраслевыми стандартами и условиями

Деятельность организаций должна соответствовать федеральным нормативным требованиям США, включая раздел 404 закона Сарбейнса-Оксли в редакции 2002 года или закон HIPAA CFR 21. К отраслевым стандартам относятся рекомендации таких организаций, как IEEE, ISO и ANSI, а также авторитетные инфраструктуры ISACA Cobit и itSMF ITIL v3. Эти рекомендации часто требуют разделения обязанностей, которое в значительной степени облегчает применение полностью автоматизированных процедур сборки, упаковки и развертывания приложений.

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

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

Ретроспективы и изменение

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

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

Заключение

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

Зрелая гибкая разработка ПО должна также сосуществовать с негибкими процессами и обеспечивать прозрачность, предоставляя четкую и точную информацию, которая необходима для ИТ-руководства и соответствия нормативным документам. Гибкость работает! Зрелая гибкая разработка поднимает практики разработки на новый уровень, делая их еще более ценными и конкурентоспособными.