ОБЗОРЫ
Методологическая гибкость
Гибкие (agile) методики создания ПО активно применяются софтверными фирмами самого разного размера по всему миру, а их поддержка сегодня встраивается непосредственно в среды разработки Microsoft, Borland, Eclipse и др. Наиболее популярной и распространенной методикой считается экстремальное программирование XP (сайты www.xprogramming.ru и www.extremeprogramming.org, статья “Программная инженерия развивается экстремальными методами”, PC Week/RE, N 35/2001, с. 36). Оно было предложено в начале 90-х гг. известным специалистом по программной инженерии Кентом Бэком, одним из авторов языка SmallTalk, который впервые успешно применил XP в 1996 г. в проекте с автомобильным производителем DaimlerChrysler.
Принципы, заложенные в XP, неоднократно расширялись и были воплощены в немалом числе управленческих и проектных технологий. Так, группа руководителей проектов и тренеров по XP сформировала несколько лет назад компанию Industrial Logic (industriallogic. com) и стала пропагандировать проверенную личным опытом управленческую методологию для софтверных фирм “промышленное экстремальное программирование”, (Industrial XP, IXP; industrialxp.org). Она представляет собой корпоративный вариант XP, который не просто охватывает деятельность программистов, а глубоко встраивается в организацию, затрагивая при этом все уровни проектного управления.
Industrial XP базируется на так называемых коллективных ценностях, которые должен принять каждый член рабочей группы. Согласие сотрудников в их отношении считается в IXP важнее, чем, например, соблюдение правил в XP, которые в данном случае вторичны по отношению к корпоративным ценностям.
В XP выделяются четыре ценности: тесное взаимодействие, постоянная обратная связь, храбрость и простота, а при использовании IXP, полагают ее авторы, каждый коллектив может выработать собственные значимые вещи. Для этого все сотрудники предлагают по пять важных для себя понятий, и наиболее часто упоминаемые автоматически становятся корпоративными. Авторы IXP в собственных проектах выделили такие ценности: тесное взаимодействие, удовлетворение от работы, постоянное обучение, тотальное упрощение и высокое качество.
Структура IXP
Каждая из пяти ценностей раскладывается на ряд конкретных управленческих принципов.
1. Тесное взаимодействие.
Оценить готовность коллектива. Перед началом проекта сотрудники определяют, насколько успешно способны организовать свой труд на основе корпоративных ценностей. Проверяется также готовность технических и программных средств и качество связи с заказчиком, вспоминается история прошлых проектов, намечаются действия по улучшению работы и соблюдению организационной культуры.
Непрерывно анализировать риски. В коллективе в любой момент может случиться непредвиденное происшествие - например, увольняется ведущий специалист, ключевой представитель заказчика уезжает в длительную командировку, а вирусы внезапно уничтожают все наработки. Поэтому менеджеры проекта ведут список возможных рисков, вывешивая его на видном месте, и указывают, как можно будет смягчить последствия того или иного происшествия.
Знать, куда движется проект. Цель проекта должна быть ясна и поддержана всеми сотрудниками. Для этого в общедоступное описание проекта включаются критерии его успеха, степень соответствия общему направлению развития компании, а также миссия, ценности, ресурсы, возможные ограничения и должностные инструкции.
***
В экстремальном программировании (XP) ценятся тесное взаимодействие, постоянная обратная связь, храбрость и простота.
***
Определить сообщество проекта. Обычно под сообществом понимается группа прямых исполнителей проекта, но в IXP в это понятие вкладывается более широкий смысл - к сообществу относятся все люди, связанные с достижением цели, от представителей заказчика до продавцов. Важно правильно учесть вклад каждого из них.
Управление, основанное на тестировании. Единственный практический способ выяснить, правильно ли работает ПО, - это протестировать его. Данный принцип, на котором построено XP, распространяется в случае IXP на всю проектную деятельность, для чего готовятся тесты, относящиеся к управленческим действиям. Хорошие тесты должны удовлетворять принципу ВИДРО*1 (время, измерение, достижение, разумность, определенность) и представляют собой необсуждаемую, четко сформулированную и измеряемую (в абсолютных значениях либо процентах) цель с ограничениями по времени. При этом результативность теста указывается в “двоичной” форме: тест либо выполнен (полностью уложился в срок и удовлетворил всем указанным критериям), либо нет, промежуточные состояния не допускаются.
_____
*1 В оригинале - SMART: Specific, Measurable, Achievable, Relevant, Time-Based.
Задачей данного типа управления считается не достижение целей любыми средствами, что создает нервозность в коллективе, а выравнивание, оптимизация труда группы с учетом целей - выработка сотрудниками понимания и предназначения собственных действий в достижении успеха проекта. Поэтому в IXP не применяются такие управленческие тесты, как “завершить такую-то возможность программы к заданному числу”, - правильно указывать “внедрить 100 рабочих мест” или “повысить удовлетворенность клиентов по опросу А на 10%”.
2. Удовлетворение от проекта (как создателей, так и заказчиков).
Работать в устойчивом темпе. Этот популярный принцип экстремального программирования, фактически запрещающий труд более 40 ч в неделю, охватывает в IXP не только программистов, но и других сотрудников. Чтобы трудиться эффективно и без большого числа ошибок, надо регулярно отдыхать, не перерабатывать и лишь изредка переходить в ускоренный темп. А на рабочих местах необходимо создать комфортные условия.
Формировать небольшие команды. В крупных структурах всегда существуют проблемы со взаимодействием - коммуникации замедленны и неэффективны. Поэтому IXP предлагает формировать мелкие группы, а если проект большой, то надо выделить в нем независимые бригады.
Часто выпускать релизы продукта. Решающим в успехе софт-проекта считается грамотное управление рисками. Если команда делает некий продукт долго и без связи с заказчиком, то такую ситуацию уже можно считать большим риском - наверняка делается не то, что надо, или не так, как надо. Поэтому необходим постоянный и частый выпуск релизов - не реже раза в 1-2 недели.
3. Постоянное обучение.
Непрерывно улучшать работу. Чтобы каждый сотрудник мог вносить возрастающий вклад в общую копилку, надо несколько часов в неделю выделять на обучение, причем не только по техническим вопросам, но и по вопросам бизнеса.
Сидеть всем вместе. Этот принцип расширяет идею парного программирования XP на весь коллектив: когда все сотрудники находятся в одном помещении, общение становится максимально быстрым, и хотя новичкам подчас кажется, что в такой ситуации невозможно сконцентрироваться на работе, на практике они быстро признают, что труд плечом к плечу - самый эффективный.
4. Тотальное упрощение.
Рассказчики историй. Функциональные требования к проекту (каждое из них называется “история”, story), выработанные в процессе обсуждения с заказчиком (заказчик рассказывает истории о будущей системе), записываются на обычных липких листочках, вывешиваемых в офисе на видном месте. Разрешается указывать по каждой истории столько деталей, сколько на таком листочке уместится, если же бумажного пространства не хватает, значит, эту историю надо поделить на более мелкие.
***
В IXP стремятся к тесному взаимодействию, получению удовлетворения от работы, постоянному обучению, тотальному упрощению и высокому качеству.
***
Типичная история записывается пятью словами с помощью активных глаголов. Если заказчик не может уложиться в этот лимит, значит, полагают авторы IXP, пока он сам не знает, что хочет от конкретной возможности системы. При этом история должна быть сформулирована так, чтобы по ее описанию было легко построить тест с измеряемыми параметрами.
План релизов. Типичный проект IXP составлен из историй, реализация каждой из которых оценивается в командных неделях - определяется, сколько недель нужно всей команде для выполнения каждой истории заказчика*1.
_____
*1 Если историю А всей команде из семи человек надо реализовывать три недели, а историю Б - лишь трем сотрудникам в течение двух недель, то считается, что истории А и Б займут пять командных недель, т. е. не происходит детализации и разделения историй по конкретным сотрудникам и мелким подзадачам.
Плановые игры. После согласования сроков реализации каждой истории с заказчиком последний выбирает, в каком порядке и с каким приоритетом истории включаются в план. Этот процесс считается в IXP игровым, потому что в реальности возможности заказчика и исполнителя обычно не согласуются ни по срокам, ни по бюджету и в ходе обсуждений приходится перебирать множество вариантов в поисках компромисса. С заказчиком также согласовываются сроки и функции промежуточных релизов продукта.
Итерационное планирование. В ходе работ над проектом заказчик выбирает историю из плана, которую он хочет видеть в системе на следующем шаге, и формулирует к ней тесты, после чего начинается итерационный цикл по ее реализации длиной 1-2 недели. Внутри итерации объем работ измеряется уже не в командных неделях, а в ЕВРО (Единица Времени Облачная*1).
_____
*1 В оригинале - NUT, Nebulous Unit of Time.
Что это за единица, создатели IPX не знают сами и предлагают каждой команде разработчиков выработать собственное определение. Очень отдаленная аналогия у ЕВРО может быть с одним днем работы команды. Так, простая история может потребовать усилий в 1 ЕВРО, сложная - 5-10 ЕВРО. Признаком хорошего планирования работ можно считать обсуждение с заказчиком трудоемкости историй не только в командных неделях, но и в более мелких ЕВРО - когда заказчик начнет достаточно точно мыслить в этих единицах, значит, с ним достигнуто полное взаимопонимание.
Тестирование историй. Перед сдачей результатов итерации работа проходит внутреннюю проверку - выясняется, отвечает ли она критерию теста, и лишь потом передается заказчику. Обычно, если история реализована за итерацию не на 100%, а, например, на 99%, работа считается невыполненной.
Итеративное использование. Процесс тестирования желательно контролировать с помощью какой-нибудь службы версионного контроля - это облегчает взаимодействие с заказчиком.
Непрерывная интеграция с бизнесом клиента. Выпуск релизов желательно автоматизировать (например, с помощью общедоступной системы cruisecontrol. sourceforge.net) - после прохода теста версия продукта сразу выкладывается в доступ пользователю.
Эволюционное проектирование. Джошуа Кириевски и Расс Рафер, известные специалисты по XP и теории программирования на основе шаблонов, разработали концепцию эволюционного проектирования ПО, которая задействована в IXP. В ее основу положены следующие принципы:
- система растет постепенно, начиная с примитивных возможностей, которые избирательно становятся зрелыми;
- развитие управляется тестами;
- активно применяется рефакторинг;
- с заказчиком поддерживается непрерывная обратная связь;
- риск снижается за счет множества автоматически выполняемых тестов;
- в интерфейсе пользователя не используются жесткие конструкции;
- отсутствует работа по четким фазам.
Разработка управляется тестированием историй. Дополнительный код по некоторой истории пишется, только если она не завершена - не прошла тест.
Коллективное владение. Любой программист может изменить в проекте что угодно и когда угодно и работает над самыми разными участками кода, поэтому в проекте невозможно определить персональную ответственность за какой-либо модуль системы - все отвечают за все.
Стандарты кодирования. Так как работа над кодом ведется всем коллективом, необходимо готовить исходные тексты в едином формате.
5. Высокое качество.
Рефакторинг. Рефакторинг и использование шаблонов проектирования обеспечивают простой и понятный код.
Проектирование, управляемое темой проекта. По результатам анализа требований заказчика обычно формируется модель будущей системы, например, на UML. Задача менеджера IXP - организовать ее проектирование, используя конкретные термины автоматизируемой предметной области, понятные и исполнителю, и заказчику, чтобы они могли общаться на одном языке.
Парное программирование. Этот важный принцип XP заключается в организации одновременной работы двух программистов над одним кодом - дополнительный контроль за чужим исходным текстом и возможность получить обратную связь в реальном времени существенно повышают качество продукта. В IXP парной становится почти любая деятельность, связанная с созданием историй, тестов, документации. Обычно один человек в таком режиме управляет мышью, другой - клавиатурой, и время от времени они меняются местами. Возможен вариант работы с двумя мышками, подключенными к одному ПК, а также подготовка одного кода с разных компьютеров (обычно не рекомендуемая).
Ретроспектива проекта. В конце каждой итерации проводятся промежуточные ретроспективы, по выходу релизов - пользовательские, и по окончании проекта - финальная. Она особенно важна, потому что далеко не все проблемы можно исправить в ходе проекта. Под ретроспективой в IXP понимается выявление хорошо действующих процессов, поиск того, что можно улучшить, и стремление повторить успешные моменты. При этом проводится не сбор фактов, а вырабатываются шаги по будущему улучшению своего труда.
В заключение
Число гибких методик постоянно растет, и в силу простоты они по праву завоевывают популярность у разработчиков. Некоторые элементы agile-подходов - такие, как парное программирование или ведение требований к системе на клейких листочках, выглядят несколько необычно, однако они воплощают в себе успешную и проверенную управленческую практику тысяч программных проектов. А главное, их внедрение не требует привлечения дополнительных ресурсов - достаточно прочитать данную статью и материалы сайта IXP и сразу начать действовать.
