В индустрии программного обеспечения считается, что разработка методом "водопад" не в состоянии справиться с быстро меняющимися требованиями, и при разработке современного ПО это становится все более очевидным. Однако в некоторых областях, таких как разработка аппаратуры, этот метод все еще пользуется популярностью. Здесь мы знакомим читателя с проблемами и практическими рекомендациями по выполнению таких проектов методом гибкой разработки с применением IBM Rational Team Concert.
С помощью Rational Team Concert наша группа переходит от метода "водопад" к методу гибкой разработки. Но не все решаются попробовать гибкий подход по ряду причин:
- группы разработки сильно зависят от различных условий, таких как график поставок оборудования, работа отдела системного тестирования, ПО с открытым исходным кодом, независимые поставщики оборудования, производители конструктивных блоков системы (building block owners - BBO) и т.п. Эти зависимости затрудняют отношения и их отслеживание;
- им нужно планировать проекты на будущий год, но когда более половины работ относятся к аппаратному обеспечению, это трудно сделать;
- большинство групп предпочитает отчеты в формате таблицы; однако этот подход чреват ошибками из-за плохого управления версиями. Группы должны получать согласованные и точные отчеты в режиме реального времени;
- им нужен способ управления требованиями и приоритетами в хорошо организованном репозитории на протяжении всего цикла разработки;
- нужен простой способ поэтапного рассмотрения и обсуждения проектов.
Основной идеей гибкой разработки являются итерации, то есть частое выполнение мелких этапов работ вместо выпуска всего пакета по истечении длительного периода времени. В начале проекта все зависимости и детальные планы не рассматриваются. Вместо этого строятся более общие планы. С помощью продуктов семейства Rational планы и зависимости можно легко редактировать и синхронизировать, чтобы участники процесса могли получать последовательную актуальную информацию внутри инструментов и централизованно обсуждать эти артефакты независимо от географического местоположения каждого члена команды.
Соображения по переходу к гибкой разработке
Когда наша группа перешла на гибкую разработку, мы внесли некоторые настройки в Rational Team Concert и приспособили процесс к выполнению наших проектов ToolsCenter.
Управление данными проекта с помощью запросов
Одна из причин, по которым мы используем Rational Team Concert, заключается в том, что он предлагает способ динамического отображения данных в режиме реального времени. Чтобы использовать эту функцию, мы создали несколько запросов в соответствии с определенными правилами, установленными для наших проектов.
Большинство наших рабочих компонентов поддерживает различные типы оборудования из семейства серверов IBM System X, включая новые системы и дополнительные платы, поставляемые различными подразделениями IBM и внешними поставщиками.
Для каждого типа оборудования мы создаем историю эксплуатации в Rational Team Concert. Для поддержки каждого типа оборудования требуется указать дату поставки оборудования, поставщиков CIM и утилиту от поставщика оборудования, драйверы устройств и микропрограммные обеспечение от BBO, которые являются подразделениями IBM.
Иногда происходят задержки в выполнении графика проекта. В организационных целях мы определили несколько признаков для различных ситуаций зависимости в области аппаратуры. С помощью этих признаков мы создали специальный запрос, чтобы получить все истории эксплуатации оборудования данного типа в определенных обстоятельствах. На рисунке 1 показаны детали запроса по оборудованию, на которое еще не получена дата поставки прошивки или драйвера от BBO.
Рисунок 1. Запрос с использованием признаков
Отслеживание зависимостей, по которым есть препятствия
Одна из ключевых проблем в наших проектах заключается в том, что важную роль играет отслеживание зависимостей. Наш проект - это комплекс программного обеспечения, который включает в себя зависящие друг от друга функции диагностики, обновления, настройки и внедрения. Поддержку технологии компонентов обеспечивают для нас другие группы. Иногда приходится исправлять дефекты в этих компонентах, прежде чем мы сможем включить их в свои инструменты и отдать на тестирование. Такие ситуации указывают на наличие зависимостей.
Наша группа и группа компонентов используют одно и то же хранилище ToolsCenter в Rational Team Concert. Для отслеживания зависимостей мы используем встроенную функцию impediment (препятствие).
Как показано на рисунке 2, рабочий элемент 477192 в инструменте диагностики зависит от изменения кода в базовой специализированной операционной системе Linux IBM. Поэтому мы сначала создали элемент impediment для зависимой группы CCB. Затем мы добавили impediment в качестве ссылки на исходный рабочий элемент 477192, как показано в верхнем правом углу рисунка 2.
Рисунок 2. Использование элемента impediment для отслеживания зависимостей
Организация журнала работ с помощью вики-страниц
В процессе перехода мы оценили преимущество вики и использовали эту технологию в Rational Team Concert. Мы считаем, что простота обращения к вики-страницам ― одна из главных причин, по которым люди их предпочитают. В нашем проекте было важно организовать все так, чтобы получать подробную информацию в кратчайшие сроки.
Мы создали несколько вкладок в журнале работ по изделию каждого выпуска со следующими категориями информации.
- Обзор: содержит самые важные данные, включая описание функций, карту функций, спринт-план и имена членов группы. Этапы отображаются в виде снимка состояния.
- Достижения: содержит сведения о том, что сделано за неделю. Руководитель группы обновляет эту страницу раз в неделю, изменяя один-два элемента.
- Дефекты: содержит график анализа дефектов за неделю. Этот график составляется, исходя из дефектов, перечисленных в Rational ClearQuest. На этой же странице хранится информация о том, где открывать дефекты для определенных групп.
- Поле выпуска и поддержки: содержит одну таблицу с предопределенными столбцами для размещения всей информации по одной проблеме.
- Приоритетная область: основные вопросы, на которых группе следует сосредоточиться на следующей неделе.
- Инновации: идеи, которые приходят во время разработки проекта.
- Ключевые вопросы: важные вопросы, возникающие в ходе выполнения проекта.
- Усвоенные уроки: практические рекомендации и болевые точки за каждую неделю.
Рисунок 3. Обзор проекта на основе вики
Каждая вкладка представляет собой снимок текущего состояния по различным аспектам наших проектов и используется главным образом в качестве входных данных для еженедельного обзора состояния проекта.
Перед каждым обзорным совещанием члены группы обновляют страницы в соответствии с текущим состоянием. В ходе обзорного совещания участники проекта получают общее представление на основе этой информации и могут делать выводы и принимать решения.
Страница достижений предназначена главным образом для того, чтобы члены группы знали о ходе дел, и не требует дополнительных усилий по ведению журнала. Содержание страницы дефектов находится в стадии разработки и, возможно, будет использоваться в будущем, когда мы полностью переведем управление дефектами на RTC. Страница проблем и поддержки и страница ключевых вопросов имеют особенно большое значение для участников процесса, так как гибкая разработка собственно и предназначена для скорейшего решения проблем. Информация, изложенная в этих вкладках, помогает быстрее двигаться вперед, обсуждая те или иные вопросы и принимая решения.
После обзорного совещания часто составляются резюме и планы действий, которые помещаются на эти вкладки в качестве задания на следующую неделю. Так процесс двигается вперед вплоть до окончания проекта.
Последующие шаги по переводу проектов
Хотя наша группа перевела большинство своих проектов на Rational Team Concert, следующие задачи еще ждут своего решения.
Как уже отмечалось, мы используем Rational ClearQuest для управления всеми дефектами наших проектов, которые еще не включены в RTC. Чтобы сделать наши проекты более централизованными, в будущем может понадобиться решение для двухсторонней синхронизации между Rational ClearQuest и Team Concert со стороны сервера RTC.
У каждой группы есть свои собственные предпочтительные инструменты управления исходным кодом, но целью является достижение централизованного управления и более полной интеграции. Наряду с RTC хорошим выбором является также Jazz SCM.
Эта статья дает практические рекомендации по использованию Rational Team Concert для действенного и эффективного решения проблем, возникающих при выполнении проектов с зависимостями, указывая основные болевые точки таких проектов.
Она содержит также рекомендации по ведению проектов, основанных на использовании методов гибкой разработки, особенно проектов по разработке оборудования. Ее можно применять в качестве руководства по переходу на гибкую разработку или в качестве практических рекомендаций, если вы уже работаете в гибкой среде.