|
Страница 4 из 5
Базовая модель адаптивного процесса Итеративный цикл "Speculate/Collaborate/Learn" ("Обдумывание/Взаимодействие/Обучение") годится для общего описания процесса, но для того, чтобы действительно производить на его основе программный продукт, нужно подробнее остановиться на некоторых деталях. На рисунке 2 изображена базовая модель адаптивного процесса со всеми его компонентами.
Обдумывание: Начальная фаза проекта и планирование циклов разработки "Обдумывание" состоит из семи последовательных шагов: - Провести начальную фазу проекта.
- Определить временные рамки проекта.
- Определить оптимальное количество циклов и временные рамки каждого из них.
- Расписать основные задачи по всем циклам.
- Связать разрабатываемые компоненты системы с соответствующими циклами.
- Связать с циклами технологические компоненты и компоненты поддержки.
- Разработать список задач по проекту.
В адаптивном процессе начальная фаза проекта немногим отличается от той, которая существует в любом нормальном процессе управления проектами. Она включает в себя определение целей и задач проекта, осмысление и документирование различных ограничений, изучение расстановки сил в проекте (то есть организацию самого проекта и определение ключевых фигур), выявление и краткое описание требований к системе, первоначальную оценку размера и масштабности проекта, а также определение ключевых рисков. Поскольку одним из важнейших факторов, принимаемых на рассмотрение при использовании адаптивного подхода, является скорость разработки системы, то большая часть изначальной информации по проекту должна собираться во время сессий Joint Application Development (JAD, Совместная разработка программного продукта). Для небольших проектов всю начальную фазу можно уложить в недельный срок. Для более крупных целесообразно запланировать так называемый "нулевой цикл", который позволит разработчикам провести более обширные предварительные исследования и подготовительные работы. ("Нулевой цикл" отличается от всех последующих тем, что его результатом будет не реальная часть системы, а некие подготовительные материалы). Вторым шагом должно стать установление временных рамок для всего проекта. Эта оценка базируется на изначальном понимании масштаба проекта, требованиях к функциональности системы, оценках трудозатрат, ресурсах (иначе говоря, на материалах, которые собираются во время начальной фазы). Обдумывание не означает отказа от проведения оценок трудозатрат, просто необходимо понимать, что любые предварительные подсчеты могут оказаться неточными, и не нужно бояться их менять. На третьем шаге необходимо решить, за сколько циклов вы сможете создать всю систему. Кроме того, нужно задать каждому из циклов временные рамки. Для небольших и средних систем (до 5000 функциональных точек) длина каждого цикла варьируется в пределах от четырех до восьми недель. В некоторых проектах лучше всего использовать двухнедельные циклы, но есть и такие, для которых больше подойдут восьминедельные и даже более продолжительные циклы (впрочем, таких проектов совсем немного). Определять продолжительность циклов нужно исходя из общего графика разработки проекта и степени неопределенности намеченных задач. Определив количество необходимых циклов и график выполнения каждого из них, команда переходит к четвертому шагу: определяет цели и задачи для каждого цикла разработки. Четко поставленная цель должна быть не только у всего проекта в целом, но и у каждого цикла в отдельности. Промежуточные контрольные точки в конце каждого цикла призваны обеспечить доступность и обозримость создаваемого программного продукта для участников проекта. Без этой доступности и обозримости невозможно увидеть и исправить различные дефекты и ошибки, без которых не обходится ни один проект. В конце каждого цикла заказчик получает определенный набор компонентов системы, которые может (и должен) просмотреть и прокомментировать. Это позволяет ему реально увидеть и опробовать разрабатываемую систему. Для интеграции отдельных компонентов системы в течение каждого из циклов служат промежуточные сборки (builds). Они позволяют увидеть и опробовать систему самой команде разработчиков. Если система постоянно доступна для обозрения, то тестирование становится непрекращающейся и неотъемлемой частью каждого цикла, а не лихорадочной деятельностью в самом конце работ, перед сдачей продукта. Во время пятого и шестого шагов производится соотнесение определенных компонентов системы с циклами разработки. Главным критерием здесь должно быть такое правило: в конце каждого цикла заказчику поставляется видимая, осязаемая, работающая часть системы. Распределение компонентов по циклам - непростая задача. Среди многих факторов, которые оказывают влияние на принятие того или иного решения, можно назвать следующие: - В конце каждого цикла заказчику должен поставляться некий осязаемый "кусок" системы
- В первую очередь в разработку должны идти компоненты с наиболее высоким риском
- График разработки компонентов должен учитывать естественные зависимости между ними
- Балансировка расходов ресурсов
Планировать циклы исходя из разрабатываемых компонентов лучше всего с помощью электронной таблицы (см. рис. 3).
В первой колонке указаны все необходимые компоненты системы. По одной колонке отведено и на каждый из циклов. Как вы видите, когда команда принимает решение разработать определенный компонент в течение какого-либо цикла, в соответствующей строке таблицы ставится крестик. Опыт показывает, что такой тип планирования (им занимается вся команда разработчиков, а не исключительно руководитель проекта) дает возможность разработчикам гораздо лучше понять проект, чем это бывает при обычном подходе с ориентацией на задачи. Планирование, в основе которого лежит график разработки компонентов системы, отражает уникальность каждого проекта. Конечно, для таких видов деятельности как анализ, объектное моделирование или проектирование могут (и должны!) существовать "наилучшие практики", однако именно поставляемые заказчику компоненты вносят в эти виды деятельности те коррективы, которые делают их уникальными для данного конкретного проекта. И, наконец, специально для тех, кто чувствует себя неуютно без списка задач по проекту - создание каждого компонента может восприниматься как конечный результат соответствующей задачи: Создать компонент А. В список можно вносить и дополнительные задачи, которые хоть и не связаны напрямую с компонентами, но необходимы для успешного завершения работы над проектом. Однако, несмотря на то, что в план проекта и можно вносить дополнительные задачи, его основу должен составлять структурный анализ компонентов системы, а не структурный анализ работ. Взаимодействие: согласованная разработка компонентов Работающие компоненты системы появляются в результате их параллельной разработки. При этом руководителей больше должно беспокоить то, как добиться наиболее эффективного взаимодействия и обеспечить согласованность выполняемых работ, нежели вопросы проектирования, тестирования и кодирования. Как мы уже говорили, сегодня для многих проектов (например, для тех, которые разрабатывают физически удаленные друг от друга команды или постоянно меняющиеся партнеры) наибольшую важность имеет то, как люди взаимодействуют между собой, и как они справляются с неизбежно возникающей взаимозависимостью. Для небольших команд, где все разработчики работают в непосредственной близости друг от друга, тесная взаимосвязь и согласованность работ может быть достигнута неформальными методами. Все можно решить во время беседы в коридоре или порисовав немного у доски. В больших проектах все не так просто. Чтобы достичь согласованности действий в крупномасштабном проекте, нужно применять расширенный вариант адаптивного процесса. Впрочем, это тема для отдельной статьи. В небольших командах, работающих в одном месте, согласованность, параллелизм и взаимодействие можно усилить с помощью практик методологии Extreme Programming (ХР). Так, например, при парном программировании два человека работают за одним компьютером: при этом каждый непроизвольно старается отличиться, отчего улучшается общее качество работы. Совместное владение кодом (еще одна практика ХР) выводит сотрудничество между разработчиками на новый уровень. Благодаря этому подходу каждый может вносить в любой код свои собственные изменения, что заставляет всю команду работать еще более сплоченно. Все разработчики - и по отдельности, и парами - делают все возможное, чтобы максимально повысить качество дизайна системы, кода и тестовых сценариев. Отношения между людьми являются самым главным моментом современного бизнеса, как пишут в своей новой книге "The Soul at Work: Embracing Complexity Science for Business Success" ("Душа обязана трудиться или Как воспользоваться наукой о сложностях, чтобы добиться успеха в бизнесе") Роджер Луин (Roger Lewin) и Бирют Режин (Birute Regine). Отношения между людьми важны "не только по чисто человеческим причинам, но и как способ для достижения лучшей адаптивности и успеха в бизнесе", - считают эти авторы. На сегодняшний день строгий контроль и процесс (то есть, те составляющие, которые ранее были необходимы для успешного осуществления проектов) должны заменяться на альянсы между различными компаниями, совместное преодоление проблем и совместное принятие решений, а также на обмен знаниями и опытом. Обучение: Оценка качества Адаптивный подход к управлению разработками заключается в следующем: нужно определить масштаб и цели проекта, показать команде, какие компоненты ей необходимо разработать, а затем отойти в сторону и дать разработчикам самим решать, как они будут это делать. Чувство ответственности в команде поддерживается при помощи периодической оценки качества. В таком случае, качество будет расти не благодаря дотошному контролю на всех этапах работ, а благодаря формированию соответствующих критериев для выпускаемого продукта и критическому его анализу. Постоянный анализ и оценка проделанной работы - ключ к обучению. Вот то, что нужно знать в конце каждого цикла разработки: - Качество продукта с точки зрения заказчика
- Качество продукта с технической точки зрения
- Как работает команда, и какие практики она при этом использует
- Текущее положение дел в проекте
В большинстве проектов самое главное - это обеспечить заказчика возможностью работать с промежуточными версиями системы и давать комментарии разработчикам. Один из вариантов - работа с фокус группой клиентов. Основанные на концепции маркетинговых фокус групп, сессии работы с клиентскими фокус группами используются для изучения рабочей модели программы и формирования запросов на изменения. Такие сессии сходны с сессиями JAD, однако вместо того, чтобы формулировать требования к системе или разрабатывать план проекта, фокус группы клиентов занимаются просмотром самой программы. В конце концов, клиенту легче общаться с работающей программой, чем с пачкой документов или диаграмм. Если при работе с прототипами отдельные люди или небольшие группы помогают определить суть будущей программы, то работа фокус группы свидетельствует о формальном окончании работ для данного цикла. Вторым показателем качества продукта является его оценка с технической точки зрения. Стандартный способ определить техническое качество системы - это провести ее технический анализ. Пересматривать дизайн системы можно в конце каждого цикла, тогда как пересмотр кода или плана тестирования может проходить в течение самого цикла. Целью анализа должно быть обучение, а не поиск виноватых. В-третьих, необходимо следить за самим процессом работы команды, вернее, за людьми и за процессом. Для этого необходимы ретроспективные пересмотры в конце проекта, а также в конце каждого цикла. Вот какие вопросы вы должны задавать себе во время постмортемов: - Что работает?
- Что не работает?
- Чего нам нужно делать больше?
- Чего нам нужно делать меньше?
Никакая другая практика не демонстрирует способность организации к обучению, как подобный анализ. Благодаря нему мы лучше понимаем и самих себя и то, как мы работаем. И, наконец, последним пунктом нашего плана идет определение статуса проекта, что впрочем, не относится напрямую к вопросам качества. Это ведет к повторному планированию в начале каждого последующего цикла. Основные вопросы, на которые вам нужно ответить: - На какой стадии развития находится проект?
- Чем его положение отличается от того, что ожидалось по плану?
- В каком положении он должен находиться?
При использовании компонентного подхода, определение статуса проекта выглядит несколько по-другому. В методе водопада, конец каждой фазы проекта отмечен окончанием работы над определенными его артефактами (например, результатом фазы разработки спецификации является документ, в котором полностью описаны все требования к системе). При компонентном подходе статус проекта будет определяться не одним документом или артефактом, а целым рядом компонентов, которые могут находиться на разных стадиях готовности. Вполне очевидно, что далеко не каждому понравится такой метод. Многие руководители, привыкшие к традиционным методам, при компонентном подходе почувствуют, что могут частично утерять контроль и влияние на процесс. В таком случае, им лучше пересмотреть свои идеи и соображения относительно прогресса проекта. Хочется особо отметить последний из трех вопросов, касающихся статуса проекта: "В каком положении проект "должен" находиться по плану?" Поскольку изначально предполагается, что планы - это чисто умозрительные построения, то оценивать прогресс проекта, сравнивая его с запланированным, будет явно недостаточно. Помимо этого команда разработчиков и заказчики должны постоянно задавать себе вопрос: "Чему мы уже научились, и как это меняет наши представления о том, в каком состоянии должен сейчас находиться проект?" |