Лучшие статьи журнала «Компьютеры+Программы»

Здравствуйте, уважаемые читатели!

В этом выпуске рассылки публикуется статья, занявшая по результатам голосования третье место.

Александр ФЕДОРЕНКО,
sashaf@xprogramming.com.ua,
http://xprogramming.com.ua

Экстремальное руководство проектом

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

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

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

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

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

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

Организация обратной связи

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

«Разработчик — заказчик»

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

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

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

Понятие «заказчик» не обязательно воспринимать дословно. Если оперировать классическими понятиями, заказчиком может быть менеджер продукта или аналитик. Однако чем меньше промежуточных звеньев, тем лучше связь и взаимопонимание, а следовательно, конечный продукт будет ближе к желаемому. Идеологи экстремального программирования любят шутить на эту тему: заменять заказчика аналитиком — это все равно, что заменять объятия вашей мамы рукопожатием знакомого.

«Разработчик — исходный код»

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

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

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

«Менеджер — разработчик»

Менеджер в экстремальном программировании играет сразу несколько ролей. В зависимости от ситуации набор этих XP-ролей может меняться.

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

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

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

«Разработчик — внешние знания»

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

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

Ситуация — под контролем

Успех разработок в любой отрасли достигается тогда, когда к нему целенаправленно стремятся. Это относится и к программным проектам. Что же является основной целью и критерием успешности проекта в терминах XP? Ответ на этот вопрос однозначен: успех проекта — это приемлемое соответствие потребностям заказчика на момент выпуска готового продукта. На первый взгляд, цель ясна; остается выбрать хороший маршрут и следовать ему. Но на практике потребности заказчика в начале разработки проекта почти всегда расходятся с тем, что ему понадобится в конце. Идеологи экстремального программирования рекомендуют прислушиваться к потребностям заказчика даже в самом разгаре разработки и варьировать маршрут.

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

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

К сожалению, такой подход обладает рядом недостатков:

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

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

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

Рассмотрим основные показатели, за которыми должно вестись наблюдение.

Качество

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

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

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

Скорость разработки

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

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

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

Корректировка планов

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

Интервенция

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

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

Чем раньше будут выявлены такие трудности и приняты соответствующие меры, тем меньший урон будет нанесен команде и заказчику.

Планирование: участвуют все!

Что требуется от разработчика в современном XP-проекте? В первую очередь, качественные куски кода. Безусловно, модульные тесты. Конечно, быстрые алгоритмы. Но не стоит забывать, что именно разработчики оценивают предстоящую им работу, и от того, насколько верны их оценки, зависит корректность планов и успех всего проекта.

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

Заключение

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

Александр ФЕДОРЕНКО,
sashaf@xprogramming.com.ua,
http://xprogramming.com.ua

До следующего выпуска!
Елена Полонская, редактор "К+П"
www.comizdat.com

Перепечатка материалов этой рассылки разрешается только по согласованию с редакцией журнала "Компьютеры+Программы"