Содержание


Бережливая разработка программного обеспечения с помощью DevOps

Уменьшение продолжительности циклов и устранение потерь с помощью ПО Rational

Comments

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

В статье рассказывается, как решения IBM® Rational® для DevOps помогают уменьшить потери и сократить циклы разработки. Эти инструменты помогают сотрудникам повысить продуктивность рабочего времени. Непосредственные взаимодействия, такие как наблюдение проекта в действии и совместная работа по выявлению источников проблем, также являются жизненно важными аспектами бережливой разработки.

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

"Суть [системы компании Тойота] состоит в том чтобы дать каждому сотруднику возможность самому определять проблемы, решать их и вносить улучшения."

С размышлениями о принципах бережливой разработки и ее эффекте можно ознакомиться в публикациях Мэри и Тома Поппендик. В разделе Ресурсы можно найти другие книги этих авторов.

Многие успешно применяют для устранения потерь возможности IBM DevOps в сочетании с принципами бережливой разработки. Компания Forrester Consulting проанализировала клиентов IBM, использующих эти решения, и установила, что разработчики, тестировщики и менеджеры проектов экономят от 30 до 50 процентов времени для взаимодействия и совместной деятельности.

Группы и организации зачастую теряют до 40 и более процентов своих ресурсов. Основными источниками потерь являются:

  • Ненужные затраты.
  • Ненужная переделка.
  • Ненужная функциональность.
  • Создание дефектного продукта.

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

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

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

Рисунок 1. Бережливое преобразование
Рисунок 1. Бережливое преобразование
Рисунок 1. Бережливое преобразование

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

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

  • Ожидание
    Потери времени на ожидание действий других сотрудников нередко связано с отсутствием четкой передачи работы между группами.
  • Передачи и смена задач
    Частая смена задач приводит к потере времени на погружение в контекст и перенастройку среды. Зачастую задачи остаются незавершенными. Участие исполнителей в нескольких проектах приводит к потере времени.
  • Движение
    Перемещение людей и артефактов приводит к потере времени. Легко ли доступны специалисты в конкретных областях и заказчики? Могут ли разработчики получить результаты тестирования, не посещая другой офис? Где хранятся необходимые документы? Как управляются передачи?
  • Избыточные процессы
    Ненужные процессы, повторяющиеся задачи и ненужная бумажная работа приводят к потере времени. Приносит ли бумажная работа пользу заказчику?
  • Избыточная функциональность
    Реализация решения, не нужного для решения бизнес-проблемы, означает потерю времени.
  • Незавершенная работа
    Не завершенный и содержащий дефекты сценарий имеет малую ценность или вообще ее не имеет. Непонятно, будет ли такой сценарий работать в производственной среде и принесет ли он пользу бизнесу.
  • Дефекты
    Дефекты препятствуют завершению работы. Большое количество дефектов и существенный технический долг проекта приводят к потере времени. Чем быстрее выявляются и исправляются дефекты, тем меньше потери.

Инфраструктура IBM DevOps, предоставляющая непрерывный конвейер для создания и поставки ПО, содержит два основных инструмента:

  • Rational solution for Collaborative Lifecycle Management (CLM): платформа конвейера создания кода.
  • IBM® UrbanCode: платформа конвейера поставки кода.

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

  • IBM® Rational® Quality Manager
  • IBM® Rational® Requirements Composer
  • IBM® Rational Team Concert™
  • IBM® UrbanCode Deploy
  • IBM® UrbanCode Release

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

Измерение потерь и цепочек формирования ценности

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

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

Рисунок 2. Превращение идеи в рабочий продукт
Рисунок 2. Превращение идеи в рабочий продукт
Рисунок 2. Превращение идеи в рабочий продукт

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

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

  • Передача новых идей в разработку.
  • Утверждение требований и проектов.
  • Поиск необходимой проектной информации.
  • Репликация и исправление дефектов.
  • Получение и настройка среды тестирования.
  • Развертывание приложения в среде тестирования.
  • Развертывание приложения в производственной среде.

На всем протяжении цепочки формирования ценности можно использовать следующие показатели:

  • Эффективность процесса, измеряемая отношением общего продуктивного времени к затраченному времени.
  • Общая продолжительность цикла.

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

Продолжительность цикла = Продуктивное время + Потери

Эффективность = Продуктивное время / Продолжительность цикла

Для лучшего понимания этих показателей изучите пример (см. рисунок 3) цепочки формирования ценности исправления обнаруженного дефекта.

Рисунок 3. Пример цепочки формирования ценности процесса устранения дефекта
Рисунок 3. Пример цепочки формирования ценности процесса устранения дефекта
Рисунок 3. Пример цепочки формирования ценности процесса устранения дефекта

При использовании цепочек формирования ценности рекомендуется измерять продуктивное время и потери (затраченное время минус продуктивное время). В этом примере продуктивное время исправления дефекта составляет в среднем 4.24 часа, а затраченное – 16.25 часа, т.е. 12 часов составляют потери.

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

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

Рисунок 4. Отчет об эффективности устранения дефектов

Рисунок 4. Отчет об эффективности устранения дефектов
Рисунок 4. Отчет об эффективности устранения дефектов

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

Потери ожидания

Большинство потерь связано с ожиданием, в частности, в следующих типичных ситуациях:

  • Ожидание инфраструктуры.
  • Ожидание развертывания приложений.
  • Ожидание других групп.
  • Ожидание завершения экспертиз.

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

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

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

Методология IBM DevOps позволяет группам автоматизировать развертывание приложения, управлять развертыванием в каждой среде и перемещать код между средами. Развертывание можно выполнять автоматически, не тратя время на ожидание. Например, один Интернет-магазин с помощью IBM DevOps уменьшил время каждого развертывания на 95%.

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

Рисунок 5. Развертывание в облачной среде
Рисунок 5. Развертывание в облачной среде
Рисунок 5. Развертывание в облачной среде

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

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

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

Рисунок 6. Блокирование задач
Рисунок 6. Блокирование задач
Рисунок 6. Блокирование задач

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

Рисунок 7. Блокирование задач группой
Рисунок 7. Блокирование задач группой
Рисунок 7. Блокирование задач группой

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

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

Рисунок 8. Представление Pending Changes
Рисунок 8. Представление Pending Changes
Рисунок 8. Представление Pending Changes

Источником потерь на ожидание также может стать рецензирование артефактов, поскольку их разработчики часто должны ждать завершения рецензий, прежде чем двигаться дальше. Зачастую много времени тратится на отслеживание сотрудников, которые должны предоставить рецензии. IBM DevOps централизует и автоматизирует рецензирование. Артефакты (требования, проект, код и активы ПО) назначаются рецензентам в интерактивном режиме, а их комментарии собираются и представляются в удобной форме. Уведомления и напоминания рассылаются рецензентам автоматически. Как показано на рисунке 9, состояние любой рецензии можно посмотреть в любое время. Такой подход позволяет убрать потери из процесса получения рецензий на артефакты.

Рисунок 9. Экономия времени с помощью интерактивного рецензирования
Рисунок 9. Экономия времени с помощью интерактивного рецензирования
Рисунок 9. Экономия времени с помощью интерактивного рецензирования

Передачи и смена задач

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

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

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

IBM DevOps позволяет уменьшить потери при передачах между группами разработки и эксплуатации за счет таких возможностей, как:

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

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

Рисунок 10. Конвейер развертывания, отображающий версии приложений для каждой среды
Рисунок 10. Конвейер развертывания, отображающий версии приложений для каждой среды
Рисунок 10. Конвейер развертывания, отображающий версии приложений для каждой среды

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

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

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

Рисунок 12. Панели обновлений, выполненных другими группами
Рисунок 12. Панели обновлений, выполненных другими группами
Рисунок 12. Панели обновлений, выполненных другими группами

Передачи между проектами и последующими этапами

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

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

Управление активами ПО способствует решению этих проблем и уменьшает потери, обусловленные невозможностью найти нужную информацию в нужное время. Актив используется для хранения группы полезных артефактов, их контекста и метаданных, таких как код, сценарии тестирования, описание сервисов, эталонные архитектуры и бизнес-модели. В частности, продукт IBM® Rational® Asset Manager позволяет уменьшить время поиска имеющихся активов с помощью формальной классификации, тегирования и функций текстового поиска. Такой подход ускоряет поиск высококачественных активов и их загрузку в среду разработки.

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

Схема визуального поиска (см. рисунок 13), демонстрирующая взаимосвязи между активами, упрощает и ускоряет их поиск.

Рисунок 13. Визуальный поиск в Rational Asset Manager
Рисунок 13. Визуальный поиск в Rational Asset Manager
Рисунок 13. Визуальный поиск в Rational Asset Manager

Смена задач

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

Во многих книгах о персональной продуктивности (например, Getting Things Done и Do It Tomorrow) подчеркивается, что многозадачность не увеличивает скорость. При наличии двух задач скорость будет выше в случае последовательного (а не одновременного) их выполнения. Группы разработки, использующие методики Agile и Kanban, следуют этому принципу, минимизируя число одновременно обрабатываемых историй.

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

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

CLM обеспечивает прекрасную поддержку смены задач, поскольку все артефакты хранятся в CLM-репозитории. Все изменения файлов (кода, проектов или документов) привязываются к задачам. Объектами управления являются наборы изменений. Разработчик задачи может приостановить набор изменений (см. рисунок 14). Приостановка возвращает весь код к состоянию до начала изменения. Поэтому разработчики могут параллельно выполнять несколько изменений кода с минимальными затратами, необходимыми для начала работы над каждой отдельной задачей. Очевидно, что этот способ не идеален, но если постоянно приходится ждать, когда артефакт будет доступен для редактирования, функция приостановки позволит минимизировать потери ожидания и смены задач.

Рисунок 14. Экономия времени при смене задач с помощью приостановки наборов изменений
Рисунок 14. Экономия времени при смене задач с помощью приостановки наборов изменений
Рисунок 14. Экономия времени при смене задач с помощью приостановки наборов изменений

Движение

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

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

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

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

Рисунок 15. Ход выполнения в группе, отображенный в Web-браузере
Рисунок 15. Ход выполнения в группе, отображенный в Web-браузере
Рисунок 15. Ход выполнения в группе, отображенный в Web-браузере

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

Избыточные процессы

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

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

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

Рисунок 16. Процесс развертывания IBM UrbanCode
Рисунок 16. Процесс развертывания IBM UrbanCode
Рисунок 16. Процесс развертывания IBM UrbanCode

Кроме того, в CLM можно настроить принудительное применение процессов организации – функцию, которая помогает плавно провести группы через процесс. Иногда инструментальные средства затрудняют следование процессу, но при использовании CLM легче следовать процессу, чем не следовать ему. Например, если группа решает, что модульные тесты должны покрывать 70% кода, CLM может запретить поставку кода, не соответствующего этому критерию.

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

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

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

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

Избыточная функциональность

Для уменьшения избыточной функциональности используйте следующие подходы:

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

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

Рисунок 17. Попарное сравнение бизнес-идей
Рисунок 17. Попарное сравнение бизнес-идей
Рисунок 17. Попарное сравнение бизнес-идей

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

Рисунок 18. Визуальные сценарии помогают пониманию
Рисунок 18. Визуальные сценарии помогают пониманию
Рисунок 18. Визуальные сценарии помогают пониманию

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

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

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

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

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

Незавершенная работа

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

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

Средства CLM здесь могут быть полезны в нескольких отношениях:

  • CLM предоставляет панель гибкого планирования задач (см. рисунок 19), которая облегчает контроль незавершенной работы.
Рисунок 19. Панель гибкого планирования задач, отображающая незавершенную работу
Рисунок 19. Панель гибкого планирования задач, отображающая незавершенную работу
Рисунок 19. Панель гибкого планирования задач, отображающая незавершенную работу
  • Чтобы минимизировать незавершенную работу, CLM помогает группам направлять большее число разработчиков на одну и ту же область кода. При таком подходе к совместной работе каждый разработчик получает песочницу для изолированного создания кода. При необходимости разработчики могут использовать код друг друга, не вовлекая в этот процесс всю группу. Такая гибкость способствует тесному сотрудничеству, которое уменьшает объемы незавершенной работы в проекте.

Дефекты

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

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

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

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

Тестирование интеграции, обычно трудно поддающееся автоматизации, часто не выполняется из-за сложности установки всех зависимых приложений. Возможность виртуализации сервисов, предоставляемая IBM DevOps, позволяет быстро и просто виртуализировать сервисы приложений. Любое приложение (или компонент), зависящее от этих сервисов, можно протестировать с помощью виртуализированных сервисов. Использование виртуализированных сервисов позволяет существенно легче проверять правильность интеграции и работы тестируемого приложения. Эта возможность становится еще ценнее в сочетании с возможностью непрерывной поставки, которую дает IBM DevOps, поскольку на ранних этапах в средах можно использовать виртуализированные сервисы, постепенно заменяя их реальными по мере прохождения тестируемой системы через разные среды тестирования. Компания Forrester Consulting приводит пример крупного европейского банка, который за три года увеличил объемы поставки проектов на 100% (с 40 до 80 проектов ежегодно) в результате использования возможностей виртуализации тестирования и тестирования интеграции, предоставляемых инфраструктурой IBM DevOps.

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

Рисунок 20. Устранение дефекта с помощью Rational Quality Manager и IBM Rational Team Concert
Рисунок 20. Устранение дефекта с помощью Rational Quality Manager и IBM Rational Team Concert
Рисунок 20. Устранение дефекта с помощью Rational Quality Manager и IBM Rational Team Concert

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

На рисунке 21 показан гипотетический пример цикла исправления дефекта вручную.

Рисунок 21. Цикл исправления дефекта вручную
Рисунок 21. Цикл исправления дефекта вручную
Рисунок 21. Цикл исправления дефекта вручную

В этом примере исправление дефекта занимает 16.25 часа, из которых 12 часов (около 75% затраченного времени) – это потери времени. Потери времени значительно увеличивают время исправления дефектов. Результатом масштабирования этого примера на то количество дефектов, которое обычно содержит проект, может стать существенная задержка исправления кода и поставки рабочей системы заказчику.

На рисунке 22 показан этот же цикл, но с использованием CLM для улучшения сотрудничества.

Рисунок 22. Автоматизированный цикл исправления дефектов с использованием CLM
Рисунок 22. Автоматизированный цикл исправления дефектов с использованием CLM
Рисунок 22. Автоматизированный цикл исправления дефектов с использованием CLM

AltText:

В варианте с использованием CLM продуктивное время исправления дефекта уменьшается с 4.75 до 3.25 часа, а потери – с 12 до менее чем 2 часов. Еще важнее то, что теперь исправление дефекта занимает чуть больше половины дня, т.е. при двухнедельном спринте можно закрыть дефекты достаточно быстро. Такая экономия времени позволяет держать под контролем технический долг и производить высококачественное ПО, готовое к развертыванию.

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

Заключение

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

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

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

Благодарности

Авторы благодарят Уолкера Ройса (Walker Royce), Мюррея Кантора (Murray Cantor), Дэвида Зискинда (David Ziskind), Элен Дай (Helen Dai), Энтони Кестертона (Anthony Kesterton) и Тони Гроута (Tony Grout) за рецензирование статьи, комментарии и поддержку.


Ресурсы для скачивания


Похожие темы

  • Оригинал статьи: Leaner software development using DevOps (EN).
  • Введение в бережливую разработку ПО: не останавливайтесь на достигнутом, Том и Мэри Поппендик, Addison Wesley, 31 октября 2009 г.
  • Бережливая разработка ПО: гибкий инструментарий, Том и Мэри Поппендик, Addison Wesley, 2003 г. ISBN: 0-321-15078-3.
  • Истинная Тойота: принципы управления для устойчивого роста, Сатоси Хино (Satoshi Hino). Productivity Press (2005 г.). ISBN: 978-1563273001.
  • Масштабирование бережливой и гибкой разработки: интеллектуальные и организационные инструменты для масштабной скрам-разработки, Крейг Лармен (Craig Larmen) и Бас Водде (Bas Vodde), Addison-Wesley Professional, 1 издание, 2008г. ISBN: 978-0321636409.
  • Масштабирование гибкой разработки ПО: передовые методики для крупных предприятий, Дин Леффингвел (Dean Leffingwell). Addison-Wesley Professional (2007 г.). ISBN: 978-0321458193.
  • Доведение дел до завершения: искусство продуктивности без стресса, Дэвид Аллен, Piatkus Books, 2002 г. ISBN-10: 9780749922641.
  • Делай это завтра и другие секреты тайм-менеджмента, Марк Форстер (Mark Forster), Hodder & Stoughton, 2006 г. ISBN-10: 9780340909126.
  • Передовые методики сбора требований в гибкой разработке, блог Скотта Амблера (Scott Ambler).
  • Совокупный экономический эффект решения IBM Rational Solution for CLM, отчет Forrester Consulting, июнь 2013 г.
  • Принципы процесса разработки продукта: бережливая разработка второго поколения, Доналд Г. Рейнертсен (Donald G. Reinertsen), Celeritas Publishing, 29 марта 2012 г. ISBN 1935401009.
  • Успешное управление программным обеспечением: руководство и баланс, Уолкер Ройс, The Rational Edge, 2005 г.
  • Узнайте подробнее о совместном управлении жизненным циклом (CLM), обеспечивающем интеграцию Jazz-приложений, для подключения аналитиков к группам разработки и тестирования.
  • Совокупный экономический эффект решений по автоматизации тестирования и виртуализации сервисов, Forrester Research, июль 2013 г.
  • Программное обеспечение, используемое в данном подходе:
  • Следите за техническими мероприятиями и Web-трансляциями, посвященными разнообразным продуктам IBM и вопросам ИТ-отрасли.
  • Повысьте свою квалификацию. Изучите каталог Rational training and certification, содержащий ссылки на курсы по разным темам. Некоторые из них можно пройти в любом месте и в любое время. Многие курсы для начинающих доступны бесплатно.
  • Получите бесплатные ознакомительные версии программного обеспечения Rational или посетите страницу Trials and Demos.
  • Оценивайте продукты IBM наиболее подходящим для вас способом: загрузите ознакомительную версию, попробуйте продукт в Интернете, используйте продукт в облачной среде или проведите несколько часов в SOA Sandbox, изучая эффективную реализацию сервис-ориентированной архитектуры.

Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=989502
ArticleTitle=Бережливая разработка программного обеспечения с помощью DevOps
publish-date=11142014