Архивы для Март, 2012

Продолжаю серию статей «Старт проекта». Первая статья здесь – Старт проекта. Как это делать?

А в этой статье поговорим о дисциплине управления конфигурациями как таковой и о ее важности.

Сразу начну с кейса из реальной жизни:

• Заказчик прислал проект на оценку в виде нескольких документов, пусть это будут спецификации: «Spec 1 v1_1» и «Spec 2 v1_2»
• Сделали оценку работ, причем в разделе «References» указали что оценки сделаны на основе этих спецификаций
• Заказчик согласился на оценку, подписали контракт, собрали команду, начали проект
• В середине проекта выяснилось, что обещанные сроки выдержать не получается
• Поначалу «подозрение» пало на некачественный оценку работ
• Но в конечном итоге выяснилось что: А) – заказчик в начале работ «подсунул» другие спецификации (названия те же, но версии и содержание отличаются); Б) – никто не сверился, отличаются ли изначальные и новые спецификации.

А теперь еще несколько типичных проблем:

• Устраненные дефекты появляются снова
• Отсутствуют зафиксированные версии спецификаций, продукта
• Заказчику отдали старую или неполную версию продукта или его частей
• Откуда-то появился новый функционал
• Не совпадают спецификации, продукт и тестовая документация

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

Немного истории. Дисциплина, как и многие другие здравые мысли пришла от военных. Кстати еще о военных, есть статья «История проектного инструментария, нач. ХХв.» – рекомендую. Так вот, как говорит Википедия, дисциплина формализовалась в 1950-х в американских воздушных силах для контроля над компонентами сложных систем. И сейчас применяется во многих отраслях, в том числе и космической. Если говорить о более близких к ИТ вещах, то она постепенно стала компонентом CMMI, ISO 9000, ISO 10007, ITIL, PRINCE2 и т.д.

Собственно определение – Управление конфигурацией (Configuration Management, CM) – это управление наборами рабочих продуктов, их версиями, статусами и взаимосвязями.

Ключевые задачи могут немного отличаться в разных источниках, но если выделить основное, то это:

• Определение элементов конфигурации
• Учет состояний и версий
• Отслеживание запросов на изменение
• Верификация конфигураций

Причем, о первых трех в списке нужно по возможности договориться на старте проекта, лучше до подписания контракта. Давайте рассмотрим первую задачу – «Определение элементов конфигурации». На протяжении проекта производится множество разных артефактов (Work Products) – спецификации, отчеты, код, результаты инспекции кода, документация пользователя, тест кейсы, скрипты, протоколы совещаний и т.д. Некоторые из них являются Элементами Конфигурации (Configuration Items), а некоторые нет. Если по простому, то Элементы Конфигурации – это наиболее важные артефакты, это могут быть: результаты поставки заказчику; артефакты, от которых зависят другие артефакты и т.п. Например, спецификация – однозначно Элемент Конфигурации, т.к. на ее основании разрабатывается продукт, тестовая документация, делается приемка продукта и т.п. А вот отчет – вряд ли.

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

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

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

Серия статей «Старт проекта» выходит в поддержку тренинга «Успешный старт проекта», в котором темы статей рассматриваются подробнее и с практическими заданиями.

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

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

Поэтому, вопрос «зачем мы это делаем» нужно задавать себе постоянно – это очень здорово влияет на конечный результат. Войдя во вкус, вы начнете задавать себе и другие вопросы – «как доказать, что мы сделали правильно», «что делать, если цель меняется» – и многие другие очень полезные вопросы, которые выведут управление вашими (и заказчика) рисками на совершенно другой уровень.

Вторая ошибка – культ Карго касательно процессов проектной деятельности и инженерных практик. Процесс безусловно важен, но он не должен руководить. Фокус должен быть на результате, поэтому, люди, которые отвечают за процессы – не должны руководить разработкой. Тогда вы перестанете «делать процесс» и начнете делать продукт. Исключение – когда разработкой руководят люди, которые в том числе внедряют процессы как один из инструментов. Но это плохая работа. Она рано или поздно приводит к всплескам в мышлении так называемой производственной ментальности: ресурсы слишком ценны, чтобы простаивать, если ресурсы начали гнать некачественный продукт, то мы поменяем прошивку, заменим износившиеся детали на новые и более модные, изменим набор действий, запланируем его другим инструментом и все станет хорошо бла-бла-бла.

Это не работает. Это просто приведет к тому, что у нас будет 100% покрытие зелеными тестами, например, но свободный поиск руками покажет, что фича негодна. С такими всплесками нужно бороться. Например – ни одна практика не внедряется без экономического обоснования с точки зрения целей проекта, а не процесса. Потому что под процесс всегда можно оправдать А вы попробуйте честно доказать друг-другу, например, что TDD вам нужна в первую очередь как инструмент уточнения требований, а уж потом – как средство повысить качество кода. Очень много интересного узнаете о том, как вы управляете требованиями и почему у вас они часто меняются.

Ценность agile практик, кстати, как раз в том и заключается (в том числе), чтобы убрать культы, но человек слаб, поэтому он часто возводит уже agile в культ.

Третья ошибка – смещение фокуса ролей. Крамольная мысль №1 – не нужен в команде «главный выделенный архитектор», отвечающий за стратегию и фреймворк решений. Так много внимания уделяется архитектуре приложения во всех её проявлениях – архитектура, дизайне, детальный дизайн. А ведь это инструмент, не более. Потому что проектирование – это не создание технического фреймворка, это процесс решения вполне себе экономических, социальных, психологических и прочих проблем. Мы привыкли рассматривать разработку как процесс создания артефакта – работающего кода. А решаемые проблемы (заказчика и разработчика) – они не ложатся в этот фреймворк, в его структуру и иерархию – он просто выступает одним из решений.

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

Крамольная мысль №3 – наличие выделенного архитектора во много крат повышает влияние риска «любимого ребенка» и вместо реальной помощи при адаптации архитектуры под изменения требований бизнеса – начинается игра не в те ворота. Как часто вам главные архитекторы тормозили процесс изменений и рассказывали, что это сложно, невозможно и очень трудно тестировать? И ведь под благим предлогом – нам нельзя дестабилизровать проект и т.д. и т.п.

Сразу отвечаю на вопрос – а как же все-таки без архитектора? Он будет, но это будет команда опытных разработчиков. Все как-то гонят от себя мысль, что архитектуру и фреймворк проекта должен писать «кодирующий архитектор» – потому что критерии качества архитектуры в большинстве случаев проявляются только в ходе процесса создания архитектуры, а не до него. Других вариантов нет – некодирующий архитектор рано или поздно превратится в инвалида, который неспособен уточнить требования через код или внедрить инженерную практику через действие.

Иными словами, архитекторы – это опытные разработчики, которых подпирает бизнес-аналитик, не позволяя увлечься сферическим конем в вакууме, постоянно напоминая о реальных критериях качества, а не о чистоте архитектурных решений, паттернах и иерархии классов. При этом, завершив этап архитектуры, эти разработчики начинают получать обратную связь о качестве этой архитектуры путем использования – самы хороший вид обратной связи. Кстати, самая навороченная из Agile методик – Feature-Driven Development, как раз и оперирует группами архитекторов (Chief Developers).

Продолжение следует…