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

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

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

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

Во-вторых, чтобы оценить выгоду любого мероприятия по улучшению процессов, необходимо уметь измерить влияние какого-либо изменения. Сложная природа разработки программного обеспечения означает, что нереально достичь оптимального состояния при помощи какого-нибудь единичного действия; необходим многоэтапный или итеративный подход. Это повышает значимость контролируемого итеративного подхода к улучшению процессов, и именно это предлагается инструментарием IBM Measured Capability Improvement Framework (MCIF).

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

Цикл улучшения процессов

В своей статье Масштабируется ли динамическая разработка? Неверный вопрос! (EN) Гари Пэллис (Gary Pallis) настоятельно рекомендует всегда, когда это возможно, основывать процессы разработки на итеративных моделях. Он пишет, что все современные методы основаны на итеративной, инкрементной разработке. Он советует использовать этот подход в качестве основы, дополняя его методиками динамичной разработки (agile), согласованными с культурой деятельности организации и культурой проектирования.

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

Рисунок 1. Типичная итерация улучшения процессов
 

Каждый цикл проходит три этапа:

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

Что же мы хотим получить взамен (см. рисунок 2)?

Рисунок 2. Оптимальная итерация улучшения процессов
 

Чтобы достичь цели, необходимо изменить несколько моментов:

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

Использование IBM Rational Team Concert for System z может помочь в достижении этих целей в цикле разработки программного обеспечения. Рассмотрим четыре области: провисание, подъем, спад и длительность цикла разработки.

Провисание

Rational Team Concert for System z содержит набор готовых к использованию шаблонов процессов, которые можно подогнать под необходимую модель. Вы сразу же существенно продвигаетесь к достижению первой цели - облегчению реализации изменений процессов. Существует набор рекомендованных процессов, которые легко можно приспособить под вашу ситуацию, а также внедрить и использовать в любых приемлемых границах в цикле разработки. Это ПО легко использовать, что помогает быстро повысить производительность и приводит к высокому уровню признания. В результате пользователи могут сконцентрироваться на главных элементах совершенствования процесса, что способствует использованию знаний и опыта различных экспертов в новом процессе:

• Эксперты по процессам, например, преподаватели процессов динамичной разработки.
• Прикладные эксперты, понимающие процесс разработки и знающие, что разрабатывается.
• Бизнес-эксперты, знающие требования и процессы администрирования.

Главные враги на этом раннем этапе - время и затраты. Не стремитесь назначить все задачи по улучшению процессов сторонним группам или молодым группам сотрудников. Вам нужны люди наиболее опытные и наименее доступные, но необходимо использовать именно их. Вы не достигнете полного успеха без их опыта. Rational Team Concert for System z - это инструментальное средство автоматизации, поэтому, не инвестируя в опыт, вы будете автоматизировать не вполне совершенный процесс, что неизбежно приведет к не вполне совершенным результатам. Сделать быстро не означает получить удовлетворение от результатов работы!

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

Подъем

Rational Team Concert for System z - это простая в использовании инструментальная программа, которую легко осваивают пользователи. Начальное обучение не составляет труда - после установки программы все изменения процесса требуют всего лишь обучения этому процессу, а не программе. Это означает, что этап реализации, на котором из улучшения процесса извлекается выгода, можно пройти с минимальными усилиями. По мере появления новых инструментов от бизнес-партнеров Rational и пользователей, работающих на платформе Jazz или с Rational Team Concert for System z, улучшение процесса может плавно перейти также и на эти области. Для платформы разработки IBM System z®, например, IBM® Rational® Developer for System z  добавляет мощную интегрированную среду разработки к возможностям управления Rational Team Concert for System z.

Для получения как можно большей крутизны подъема важно извлекать максимальные выгоды из любого изменения процесса. Давайте рассмотрим пример разбиения работы группы разработчиков до цикла улучшения процесса. На рисунке 3 мы разбили эту работу на три категории:

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

Эффект от улучшения процесса будет заключаться в улучшении соотношения работы и переделки.

Рисунок 3. До улучшения процесса
 

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

Рисунок 4. После улучшения процесса
 

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

Rational Team Concert for System z предоставляет такую автоматизацию для гетерогенных сред разработки, к которым относится System z.

Рисунок 5. После улучшения процесса с применением автоматизации
 

Программа Rational Team Concert for System z способствует минимизации затрат на администрирование и потому, что организация может при планировании улучшения процесса принять во внимание некоторые из предлагаемых методик динамичной разработки. Одной из наиболее признанных методик динамичной разработки является scrum-управление проектами (в разделе "Ресурсы" приведена ссылка "Scrum-управление проектами с использованием Rational Team Concert, Version 2"). Scrum-собрания лучше всего работают тогда, когда разработка придерживается философии Agile One Room и осуществляется в непосредственной близости от пользователя или клиента. Scrum-собрания - это короткие, регулярные, важные собрания, на которых участники поднимают максимум три вопроса. Это работает только при наличии постоянного сотрудничества в процессе разработки. Достижение этого в ручном режиме работы или при использовании не интегрированных средств может быть проблематичным, затратным по времени и дорогостоящим.

Обычно в больших или кросс-платформенных проектах невозможно свести команду разработчиков в одном месте, поэтому Rational Team Concert for System z предоставляет мощные инструменты для коллективной работы в простой унифицированной среде. Это позволяет всем пользователям просматривать и отслеживать ход работы других сотрудников и взаимодействовать с ними, обеспечивая таким образом возможность проведения scrum-собраний и Scrum of Scrums, чтобы концентрироваться на важных вопросах. Scrum-собрания можно эффективно проводить со всеми участниками, обращающимися к своим доскам задач (taskboard) Rational Team Concert for System z (рисунок 6).

Рисунок 6. Rational Team Concert for System z Taskboard
 

Динамичная разработка использует философию, ориентированную на человека, а Rational Team Concert for System z оказывает поддержку каждому пользователю, предоставляя ему возможность доступа и взаимодействия с остальными участниками группы, а также автоматический учет.

Спад

Вернувшись к рисунку 3, можно увидеть состояние, предшествующее улучшению. После улучшения мы переходим к рисунку 4. Если процесс не контролируется, то либо в результате сознательного выбора (пользователи принимают путь наименьшего сопротивления), либо из-за отсутствия знаний разработка постепенно возвращается к состоянию, предшествующему улучшению. Ручное управление и контроль за исполнением дорого стоят, неэффективны для поддержки и требуют длительного обучения. Поэтому автоматизированная среда, которая может контролировать исполнение, отслеживать и предоставлять зависящую от контекста помощь, является важным фактором поддержки полезных сторон любого процесса. Вместо необходимости обращаться к документации и помнить о том, каким процессам нужно следовать, Rational Team Concert for System z использует базу знаний о процессах, настроенную на автоматическое обнаружение противоречий процессов в момент их возникновения. Она также обеспечивает ответную реакцию при обнаружении противоречий. Эта ответная реакция (рисунок 7) часто сопровождается предложениями по автоматическому исправлению ошибок. При желании можно разрешить отмену предварительных условий для процесса. Таким образом, можно поддерживать передовые методики и в то же время не терять гибкость.

Рисунок 7. Рекомендация для процесса в Rational Team Concert for System z
 

Длительность цикла разработки

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

• Информация для рассмотрения клиентом.
• Работоспособность системы (результатом каждой итерации должна быть работающая система).
• Уровень квалификации группы разработчиков.
• Доступность клиента.
• Знания для планирования.
• Внешние зависимости (аппаратура и т.п.).
• Длительность циклов тестирования.
• Дополнительные затраты на планирование и администрирование.

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

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

Резюме

Таким образом, улучшение процессов выгодно любой организации. Автоматизация позволяет как можно быстрее извлечь максимум пользы из такого улучшения и поддерживать ее без потери эффективности. Один из трудных аспектов здесь - улучшение процессов и автоматизация при разработке для мэйнфреймов. Rational Team Concert for System z предоставляет интегрированную среду автоматизации совершенствования процессов для гетерогенных сред разработки, к которым относится платформа System z. Это означает, что Rational Team Concert for System z позволяет реализовать методики динамичной разработки в прежде недружелюбных конфигурациях, предоставляя корпоративную среду планирования и коллективной разработки программного обеспечения. В результате все современные процессы разработки теперь применимы и для организаций, использующих системы IBM System z.