Не секрет, что состояние экономики и нестабильная ситуация на рынках ценных бумаг в первые месяцы 2008 года сильно отразились на многих компаниях, будь то крупных или небольших. В марте этого года компания Gartner сообщила, что директора по информационным технологиям должны готовиться к тому, чтобы урезать расходы на информационные технологии, дабы пережить сложную экономическую ситуаци.[1]. Проекты разработки программного обеспечения, особенно исследовательского, динамичного, прогрессивного характера, в которых по-настоящему ярко выражена гибкая методология, в настоящее время замораживаются и даже полностью отменяются до наступления каких-либо улучшений делового климата. Некоторые коллективы претерпели сокращения в числе работников, тем самым потеряв ценные интеллектуальные ресурсы в данной сфере и для работы над проектами.[2].

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

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

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

• Преимущества гибкой методологии в вопросе окупаемости инвестиций (ROI)
• Польза гибкой методологии в снижении совокупной стоимости владения (TCO)
• Значение доверия при приведении бизнес-доводов в пользу гибкой методологии

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

Когда наступают трудные времена...

"В трудных экономических условиях компании озабочены ростом доходов. Нужно защищать доходы и при этом следить за операционными расходами. Информационные технологии находятся в статье расходов, и потому обычно именно на них приходится основной удар. Во кризисные времена компании, как правило, рассматривают ИТ как расходную часть и переводят их в режим сдерживания затрат и под контроль финансового директора."[3]

Сдерживание затрат вызывает обвал, который обрушивается на менеджеров, только раздувая страхи, неуверенность и сомнения относительно применения Agile-подхода. Возникает множество вопросов относительно Agile: это рискованно; партнерским отделам требуется более предсказуемая модель реализации; Agile-проектами и командами труднее управлять. В результате у руководства возникает искушение вернуться к старой практике. В глубине души некоторые признают, что преимущества гибкой методологии в перспективе компенсируют некоторый риск в "тучные" времена, но на данный момент более тяжеловесные подходы, к которым они возвращаются, кажутся им более предпочтительными, даже если они в действительности не предлагают лучшего решения. Под натиском требований лучшего результата при малых затратах и в сложных условиях выполнения проекта некоторые менеджеры теряют веру в Agile-подход и ищут успокоения и видимых преимуществ в отчетах о статусе проекта, "водопадах" (модель процесса разработки программного обеспечения, характеризующаяся тем, что предыдущий этап полностью завершается до начала следующего - Прим. переводчика) и хорошо задокументированных проектных фазах, четко разбитых на последовательные этапы.

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

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

Экономические преимущества Agile-подхода могут быть продемонстрированы с помощью трех деловых доводов, каждый из которых предлагает сильные аргументы в пользу Agile-подхода по сравнению с традиционными подходами: окупаемость инвестиций (ROI), совокупная стоимость владения (TCO) и повышенная конкурентоспособность на рынке. Каждого из этих аргументов может быть достаточно, чтобы сохранить Agile-подход; а сочетание всех трех имеют неопровержимую силу.

Окупаемость инвестиций (ROI)

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

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

Обоснование превосходства Agile-метода над традиционными, плановыми подходами в том, что касается ROI, может дать вам возможность перевести деловое обсуждение с субъективной оценки ("с Agile все намного лучше") на объективную ("Agile-подход увеличивает окупаемость инвестиций на x%"). Разумное экономическое обоснование является мощным средством для защиты позиций Agile-подхода, когда кто-то хочет повернуть назад к хорошо знакомым, но несовершенным методам.

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

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

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

Вариант 1: Сокращение расходов, постоянная окупаемость.

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

Различия между Agile-подходом и плановой моделью ROI невелики, но они имеют решающее значение. Одно отличие состоит в том, что можно утверждать, например, что плановый подход увеличит сроки выполнения проекта от двенадцати до четырнадцати дней, то есть, на две недели. Такое различие можно формально выразить с помощью моделей наподобие COCOMO II.[4]: "Время внедрения новых или измененных возможностей системы представляет собой функцию сложности системы, процесса, затрагивающего изменения, навыков специалистов, внедряющих изменения, а также имеющегося оборудования для автоматизации работы."[5]. В качестве альтернативы, можно эмпирически отобразить дополнительное время, которое требуется для тщательного сбора данных и анализа требований, проектных планов, критериев приемочных испытаний и других необходимых факторов. Другим отличием, к которому вы можете прибегнуть в качестве аргумента, является то, что плановый подход требует большего штата сотрудников с дополнительными внутренними ресурсами для управления требованиями и планами, а также для формального взаимодействия с заинтересованными сторонами, а также внешние ресурсы для управления удаленной группой. На рисунке 1 показаны детали такого сравнения.

Рисунок 1. Сокращение расходов, постоянная окупаемость

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

Вариант 2: Фиксированные затраты, повышенная окупаемость

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

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

Как показано на рисунке 2, мы начинаем с тем же составом группы, что и в варианте 1: шесть штатных работников и шесть удаленных сотрудников. Расходы на проект фиксированные, поэтому возможность улучшить показатели ROI будет сведена исключительно к тому, насколько ваша методология сможет стимулировать рост доходов. Исследовав рынок, вы решили, что методика Agile, направленная на требования покупателя, повышает окупаемость на 20% по сравнению с плановым подходом с той же группой благодаря увеличению числа заказов от покупателей, более высокому ценовому ориентиру или и тому, и другому.

Рисунок 2. Фиксированные затраты, повышенная окупаемость

Вариант 3: Сокращение расходов, повышенная окупаемость

Многие организации, практикующие Agile-подход, открывают новые возможности в разработке программного обеспечения. Они направляют свои усилия на новые приложения, услуги и компоненты, а не на попытки пронести с собой в 21 век громоздкие унаследованные приложения. Благодаря конкурентоспособным предложениям они стимулируют развитие рынка и экономический рост.

Такие проекты идеальны для демонстрации превосходного потенциала Agile-подхода в отношении ROI. Если вы продемонстрируете более высокий уровень окупаемости при применении Agile-подхода, как показано в ROI варианте 2, наряду с эксплуатационной эффективностью и относительной экономией на расходах, как показано в варианте 1, вы получите прирост ROI на обоих концах уравнения.

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

Рисунок 3. Сокращение расходов, повышенная окупаемость

Риски и ROI

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

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

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

Имеется солидный объем коммерческой литературы о пользе Agile-подхода по сравнению с другими методиками, когда речь идет о риске, и она постоянно пополняется. В центре внимания Agile-подхода находится открытое и эффективное общение с заказчиками в сочетании с поэтапным предоставлением продукции, что в среднем повышает успех проекта на 70%[6] (при этом некоторые организации приводят даже более высокие цифры). В противоположность этому, некоторые исследования показали, что степень неудач проектов при традиционных подходах может достигать от 60% до 85%.[7]. Поэтому, даже если ваше моделирование показывает одинаковый показатель ROI как для методики Agile, так и для плановой методики, тот факт, что Agile-подход дает большую вероятность успеха, является ключевым фактором для достижения такого ROI.

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

Как правило, при Agile-подходе можно быстрее определить, что проект идет в никуда. В сложные моменты этот вопрос необходимо разрешить с менеджерами. Agile-подход позволяет эффективнее корректировать ход исполнения проекта или полностью урезать свои расходы. Методика "водопада" часто преподносится как более предсказуемый метод, но, к сожалению, вплоть до последних стадий проекта предсказанный результат часто не сбывается. Никто не планирует неудачу своего программного проекта, но когда все начинает разваливаться, предосторожность никогда не бывает лишней. Agile-подход предлагает руководству такие возможности.

Совокупная стоимость владения (TCO)

Гуру в области систем измерений ИТ-показателей и ведущий в отрасли специалист доктор Говард А. Рубин (Dr. Howard A. Rubin) предлагает получить всестороннее представление о том, что анализ расходов на технологии должен идти как сверху, так и снизу:

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

Далее он продолжает: "Начиная снизу, вам следует хорошо изучить технологии и их принципы их реализации, то есть, намного больше, чем просто знать, как много времени требуется на разработку приложений… Это означает, что вам нужно рассматривать технологию как товар по цене за единицу."[8]

Менеджеры и руководители изучают совокупную стоимость владения (TCO) сверху вниз. Но для того, чтобы учесть преимущества Agile-подхода с точки зрения TCO, нам нужно двигаться снизу вверх, чтобы на полпути прийти к компромиссному решению с руководством.

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

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

TCO в деталях

Исходя из того, что Agile-методика подходит для "бытовых" систем, как это отражается при анализе TCO? По сравнению с другими отраслями, разработка программного обеспечения требует относительно мало оборудования и много людских ресурсов. Расходы на персонал составляют от 50% до 70% типичных расходов на проекты. В целом, Agile-подход может рационализировать потребности в персонале, устранив накладные расходы на персонал, обычные для традиционных, плановых подходов. С точки зрения TCO это приносит прямую финансовую выгоду.

На рисунке 4 показаны совокупные расходы на рабочие группы с течением времени для двух рабочих групп, причем одна применяет методику Agile, а другая - плановую. Состав групп и структура расходов даны по модели ROI варианта 1, приведенной выше.

Рисунок 4. Совокупные расходы на рабочие группы с течением времени, одна группа применяет Agile, а другая - плановую методику

Agile-подход, несомненно, в состоянии помочь сохранить средства и улучшить показатели TCO. На рисунке 4 экономия на расходах превышает $750 000 в год, что на 64% выше, чем при плановой методике. Притянуто за уши? Отнюдь нет. Представленная здесь модель сочетает данные реальных проектов сопровождения программных продуктов, которые перешли из методологий типа "водопад" к методу Agile.

Такой подход "снизу-вверх" может продемонстрировать веские доводы в пользу сохранения Agile-методики и показать, что теперь это более необходимо, чем когда-либо. Постройте модель, которая отражает данные о вашей системе, рабочей группе и структуре расходов на персонал. Не забывайте о той работе, которая проделана другими до вас,[9] и о том, как применить усвоенные вами уроки.

Важно также обратить внимание на то, что сокращение числа сотрудников имеет и другие далеко идущие последствия. Меньше сотрудников значит меньше оборудования, меньше лицензий на программное обеспечение, меньше места в офисе, меньше расходов на отопление и кондиционирование. Включение в Agile-подход испытаний компонентов системы, автоматизации испытаний и непрерывной интеграции повышает качество и производительность и снижает расходы. Меньше сотрудников значит меньше активных элементов, более эффективное взаимодействие и больше возможностей для гибких условий работы. Эти факторы срабатывают в пользу таких рабочих групп по сопровождению программного обеспечения, где сотрудники из разных концов мира работают в одном виртуальном рабочем офисе; более эффективная ежедневная связь может сократить число необходимых посещений офиса. Каждое из этих преимуществ говорит об операционной эффективности и само по себе дает экономию в расходах

Повышенная конкурентоспособность

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

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

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

Доверие позволяет раскрыть процесс

"У большинства отделов ИТ нет эффективных программ для связи и маркетинга. Опять же, такие организации появились в мире бизнеса лишь недавно, а их стратегическая ценность пока неясна и выражена нечетко. Многие люди, работающие с технологиями, говорят исключительно технологическими терминами."[10]

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

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

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

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

По этой причине в нестабильных экономических условиях верность Agile-подходу вполне может привести к пересмотру доверительных отношений. Будучи сторонниками Agile, мы часто говорим нашим заказчикам и руководству: "Доверьтесь нам". И все же, мы зачастую недооцениваем те средства, которыми заказчики и руководители традиционно пользуются для того, чтобы оценить ход движения к поставленным целям, такие как проектные планы, договоры и формальные отчеты о состоянии. Если те, на кого мы работаем, не могут полностью контролировать ход нашей деятельности, то как мы сможем поддерживать прочные и долгосрочные доверительные отношения?

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

Мои предыдущие статьи по ключевым показателям эффективности[11] (KPI) и методике Goal-Question-Metric (Цель/Вопрос/Метрика, GQM)[12] рекомендуют использовать инструменты, с помощью которых можно вовлечь как можно больше талантливых сотрудников в содержательный процесс разработки программного обеспечения. Эти инструменты могут использоваться для создания порталов управленческих показателей, которые автоматизируют прозрачность процесса, а также обеспечивают соответствие стандартам руководства разработкой. Кроме того, существует пополняющийся пакет продуктов по управлению жизненным циклом приложений (Application Lifecycle Management - ALM) ¹³ для реализации и автоматизации таких инструментов, обеспечивая при этом прозрачность без необходимости взваливать на рабочую группу Agile задачи отчетности, которые отнимают много времени. Чтобы извлечь максимум преимуществ Agile-подхода в сложных экономических условиях, сделайте весь процесс открытым как для разработчиков, так и для менеджеров и укрепите доверительные отношения, не только предоставляя результаты, но и демонстрируя стабильный организованный процесс предоставления программного обеспечения.

Примечания

1. "Gartner Recommends Key Cost-Cutting Tactics in Data Management and Integration" ("Gartner рекомендует ключевые методики по сокращению расходов в области управления данными и интеграции"), пресс-релиз Gartner, 03.10.2008 (http://www.gartner.com/it/page.jsp?id=619108)
2. "[E]ven with 2008 budgets approved and IT decision makers looking forward to improving IT resources in the coming months, the greenlighting of actual technology investments will depend on the overall economic environment, which remains uncertain." ("Несмотря на уже утвержденные бюджеты на 2008 год и желании руководителей в сфере ИТ усовершенствовать ИТ-ресурсы в ближайшие месяцы, реальный процесс инвестирования в технологии будет зависеть от общей экономической ситуации, которая остается неопределенной. ") из пресс-релиза "IT Decision Makers Offer a Little Hope for 2008" ("Руководители в сфере ИТ возлагают мало надежд на 2008 год ") CDW IT Monitor, 03.05.2008.
3. "The Cost Of Bad IT Economics" ("Цена слабой экономики информационных технологий"), журнал CIO Insight , 02.11.2008.
4. Software Cost Estimation with COCOMO II (Расчет стоимости программного обеспечения с помощью COCOMO II) , Барри Боэм и др. (Barry Boehm, et al), Prentice Hall PTR, август 2000 г. .
5. "Improving Software Development Economics, Part I: Current Trends" ("Улучшение экономики разработок программного обеспечения. Часть I: Текущие тенденции"), Уолкер Ройс (Walker Royce), The Rational Edge , апрель 2001 г.
6. "Defining Success" ("Определение успеха"), Скотт В. Эмблер (Scott W. Ambler), Dr. Dobb's Portal, 10.31.2007 (http://www.ddj.com/architect/202800777)
7. Многочисленные ссылки; см. "Waterfall Method: A Colossal Blunder!" ("Метод "водопада": Колоссальная ошибка!"), Джефф Сазерлэнд (Jeff Sutherland), 10.07.2004.
8. "A CAI State of the Practice Interview with Dr. Howard Rubin" ("Обзор состояния дел CAI, интервью с доктором Говардом Рубином "), The IT Metrics and Productivity Institute, январь 2006 г.
9. Многие специалисты по Agile-методике пишут и говорят о TCO; среди них такие специалисты в отрасли как Скотт Эмблер (Scott Ambler) (практикующий разработчик по методике Agile, IBM) и Джефф Сазерлэнд (Jeff Sutherland) (соавтор Scrum).
10. "The Cost Of Bad IT Economics" ("Цена слабой экономики информационных технологий"), журнал CIO Insight , 02.11.2008.
11. "Development governance for software management" ("Советы по управлению проектами разработки ПО для руководителей по программному обеспечению", The Rational Edge , 10.16.2007 (http://www.ibm.com/developerworks/rational/library/oct07/dunn/index.html)
12. "Achieving governance goals with GQM" ("Достижение целей управления с помощью GQM"), The Rational Edge , 03.15.2008 (http://www.ibm.com/developerworks/rational/library/edge/08/mar08/dunn/index.html)
13. См., например, часть 3 серии статей "Application lifecycle management with ClearQuest 7.1.0.0" ("Управление жизненным циклом приложений с помощью ClearQuest 7.1.0.0") в этом номере The Rational Edge .