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

1. «Waterfall Model» (каскадная модель или «водопад»)

Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.

С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний - рентгеновский микротомограф , мелкий - автообновление службы Windows на AWS .

Когда использовать каскадную методологию?

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

2. «V-Model»

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

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

Когда использовать V-модель?

• Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
• Для малых и средних проектов, где требования четко определены и фиксированы.
• В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

3. «Incremental Model» (инкрементная модель)

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

Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.

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

Когда использовать инкрементную модель?

• Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
• Требуется ранний вывод продукта на рынок.
• Есть несколько рисковых фич или целей.

4. «RAD Model» (rapid application development model или быстрая разработка приложений)

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

Модель быстрой разработки приложений включает следующие фазы:

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

Когда используется RAD-модель?

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

5. «Agile Model» (гибкая методология разработки)

В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.

В основе такого типа - непродолжительные ежедневные встречи - «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:

• отчёт о проделанной работе с момента последнего Scrum’a;
• список задач, которые сотрудник должен выполнить до следующего собрания;
• затруднения, возникшие в ходе работы.

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

Когда использовать Agile?

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

6. «Iterative Model» (итеративная или итерационная модель)

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

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

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

Когда оптимально использовать итеративную модель?

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

7. «Spiral Model» (спиральная модель)

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

Спиральная модель предполагает 4 этапа для каждого витка:

1. планирование;
2. анализ рисков;
3. конструирование;
4. оценка результата и при удовлетворительном качестве переход к новому витку.

Эта модель не подойдет для малых проектов, она резонна для сложных и дорогих, например, таких, как разработка системы документооборота для банка, когда каждый следующий шаг требует большего анализа для оценки последствий, чем программирование. На проекте по разработке СЭД для ОДУ Сибири СО ЕЭС два совещания об изменении кодификации разделов электронного архива занимают в 10 раз больше времени, чем объединение двух папок программистом. Государственные проекты, в которых мы участвовали, начинались с подготовки экспертным сообществом дорогостоящей концепции, которая отнюдь не всегда бесполезна, поскольку окупается в масштабах страны.

Подытожим

На слайде продемонстрированы различия двух наиболее распространенных методологий.

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

О технологиях разработки:
Ещё раз про семь основных методологий разработки .
10 главных ошибок масштабирования систем .
8 принципов планирования разработки, упрощающих жизнь .
5 главных рисков при заказной разработке ПО .

Только зарегистрированные пользователи могут участвовать в опросе. , пожалуйста.

Rapid Application Development (RAD) - это жизненный цикл процесса проектирования, созданный для достижения более высоких скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.

Концепция RAD стала ответом на методы разработки программ 1970-х и начала 1980-х годов, такие как «модель водопада». Эти методы предусматривали настолько медленный процесс создания программы, что зачастую даже требования к программе успевали измениться до окончания разработки. Основателем RAD считается сотрудник IBM Джеймс Мартин, который в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях Барри Бойма и Скотта Шульца. А в 1991 году Мартин опубликовал известную книгу, в которой детально изложил концепцию RAD и возможности её применения. В настоящее время RAD становится общепринятой схемой для создания средств разработки программных продуктов.

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

фаза анализа и планирования требований;

фаза проектирования;

фаза построения;

фаза внедрения.

На стадии анализа и планирования требований пользователи осуществляют следующие действия:

определение функций, которые должна выполнять система;

выделение наиболее приоритетных функций, требующих проработки в первую очередь;

описание информационных потребностей.

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

ограничивается масштаб проекта;

устанавливаются временные рамки для каждой из последующих стадий;

определяется сама возможность реализации проекта в заданных размерах финансирования на имеющихся аппаратных средствах и т.п. Результатом стадии должны быть:

список расположенных по приоритету функций будущего ПО ИС;

предварительные модели ПО.

На стадии проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. Для быстрого получения работающих прототипов приложений используются соответствующие инструментальные средства (CASE-средства). Пользователи, непосредственно взаимодействуя с разработчиками, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей стадии. На данной стадии выполняются следующие действия:

более детально рассматриваются процессы системы;

при необходимости для каждого элементарного процесса создается частичный прототип (экранная форма, диалог, отчет, устраняющий неясности или неоднозначности);

устанавливаются требования разграничения доступа к данным;

определяется состав необходимой документации.

Далее проект распределяется между различными командами разработчиков. В случае использования CASE-средств это означает деление функциональной модели системы (диаграммы потоков данных для структурного подхода или диаграммы вариантов использования для объектно-ориентированного подхода). Результатом данной стадии должны быть:

общая информационная модель системы;

функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

точно определенные интерфейсы между автономно разрабатываемыми подсистемами;

построенные прототипы экранных форм, отчетов, диалогов.

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

На стадии реализации выполняется быстрая разработка приложения:

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

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

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

осуществляется анализ использования данных и определяется необходимость их распределения;

производится физическое проектирование базы данных;

формулируются требования к аппаратным ресурсам;

устанавливаются способы увеличения производительности;

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

На стадии внедрения производится обучение пользователей и организационные изменения.

Применение технологии RAD целесообразно, когда:

требуется выполнение проекта в сжатые сроки (90 дней);

нечетко определены требования к ПО;

проект выполняется в условиях ограниченности бюджета;

интерфейс пользователя (GUI) есть главный фактор;

проект большой, но поддается разделению на более мелкие функциональные компоненты;

ПО не обладает большой вычислительной сложностью.

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

Рисунок 1 - Сравнение RAD и Каскадного метода

Среда быстрой разработки приложений Delphi

Современные масштабы разработки программного обеспечения немыслимы без средств RAD.

RAD (от англ. «rapid application development» - быстрая разработка приложений) - концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. С конца XX в. RAD получила широкое распространение и одобрение. Концепцию RAD также часто связывают с концепцией визуального программирования.

Основные принципы создания RAD-проектов:

· инструментарий должен быть нацелен на минимизацию времени разработки.

· создание прототипа для уточнения требований заказчика.

· цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком.

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

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

· управление проектом должно минимизировать длительность цикла разработки.

Концепция RAD стала ответом на неуклюжие методы разработки программ 1970-х и начала 1980-х гг. Эти методы предусматривали настолько медленный процесс создания программы, что зачастую даже требования к программе успевали измениться до окончания разработки. Основателем RAD считается сотрудник IBM Д. Мартин, который в 1980-х гг. сформулировал основные принципы RAD, основываясь на идеях Б. Бойма и С. Шульца. В настоящее время RAD становится общепринятой схемой для создания средств разработки программных продуктов. Именно средства разработки, основанные на RAD, имеют наибольшую популярность среди программистов.

Среды разработки, использующие принципы RAD:

· Borland Delphi.

· Borland C++ Builder.

· IBM Lotus Domino Designer.

· Microsoft Visual Studio.

· Macromedia Flash и др.

Одной из самых распространенных сред RAD является Delphi.

Borland Delphi - это интегрированная среда разработки программного обеспечения фирмы Borland, использует язык программирования Delphi (начиная с 7 версии язык в среде именуется Delphi, ранее - Object Pascal), разработанный фирмой Borland и изначально реализованный в её пакете Borland Delphi, от которого и получил в 2003 году своё нынешнее название. Object Pascal по сути является наследником языка Pascal с объектно-ориентированными расширениями.

Delphi - результат развития языка Турбо Паскаль, который, в свою очередь, развился из языка Паскаль. Паскаль был полностью процедурным языком, Турбо Паскаль начиная с версии 5.5 добавил в Паскаль объектно-ориентированные свойства, а Delphi - объектно-ориентированный язык программирования с возможностью доступа к метаданным классов (то есть к описанию классов и их членов) в компилируемом коде, также называемом интроспекцией. Де-факто Object Pascal, а затем и язык Delphi являются функциональными наращиваниями Turbo Pascal.

Среди многих распространенных программных продуктов, сделанных на Delphi, можно найти:

· продукция Borland: Borland Delphi, Borland C++ Builder.

· администрирование / разработка баз данных: MySQL Tools (Administrator, Query Browser), TOAD.

· инженерное ПО: Altium Designer / Protel (проектирование электроники).

· доставка информации в Интернете: Skype (VoIP и IM), QIP и QIP Infium, The Bat! (клиент электронной почты).

В процессе построения приложения в Delphi разработчик выбирает из палитры компонент готовые компоненты. Основной упор в объектно-ориентированной модели программных компонент в Delphi делается на максимальном использовании кода. Это позволяет разработчикам строить приложения весьма быстро из заранее подготовленных объектов, а также дает им возможность создавать свои собственные объекты для среды Delphi.

Cреда Delphi включает в себя полный набор визуальных инструментов для скоростной разработки приложений, поддерживающей разработку пользовательского интерфейса и подключение к корпоративным базам данных. VCL - библиотека визуальных компонент, включает в себя стандартные объекты построения пользовательского интерфейса, объекты управления данными, графические объекты, объекты мультимедиа, диалоги и объекты управления файлами, управление OLE.

На рис. 7.3 приведено основное окно среды Delphi во время разработки моделирующей программы для процессов производства ЛАБ.

Рис. 7.3. Основное окно среды Delphi во время разработки моделирующей программы для процессов производства ЛАБ

Объекты баз данных в Delphi основаны на SQL. В состав Delphi также включен Borland SQL Link, поэтому доступ к СУБД Oracle, Sybase, Informix и InterBase происходит с высокой эффективностью. Кроме того, Delphi включает в себя локальный сервер Interbase для того, чтобы можно было разработать расширяемые на любые внешние SQL-сервера приложения. Разработчик в среде Delphi, проектирующий информационную систему, может использовать для хранения информации файлы формата *.dbf (как в dBase или Clipper) или *.db (Paradox).

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

Благодаря открытой компонентной архитектуре приложения, изготовленные при помощи Delphi, работают надежно и устойчиво. Delphi поддерживает использование уже существующих объектов, включая DLL, написанные на С и С++, OLE сервера, VBX, объекты, созданные при помощи Delphi. Кроме того, поскольку Delphi имеет полностью объектную ориентацию, разработчики могут создавать свои повторно используемые объекты для того, чтобы уменьшить затраты на разработку.

Библиотека визуальных компонент включает в себя стандартные объекты построения пользовательского интерфейса, объекты управления данными, графические объекты, объекты мультимедиа, диалоги и объекты управления файлами, управление DDE и OLE.

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

В конце 2002 года московское издательство "Лори" выпустило книгу Алистера Коберна (Alistair Cockburn) "Быстрая разработка программного обеспечения". Русское название книги немного удивляет, потому что в оригинале она называется "Agile Software Development" и более правильный перевод звучал бы как "Гибкая разработка ПО". Впрочем, не будем придираться к переводчику, потому что подобных книг на русском языке еще не издавалось.

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

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

Периодически находились люди, которые начинали понимать проблемы создания ПО, но настоящий прорыв происходит именно теперь, после появления экстремального программирования (eXtreme Programming, www.extremeprogramming.com) и создания альянса гибкой разработки ПО (Agile Alliance, www.agilealliance.org). Гибкие методологии ломают стереотипы и полностью изменяют процесс разработки программ. Они изменяют сами принципы организации процесса.

Чем же отличаются гибкие методологии от традиционных? Можно выделить несколько основных отличий:

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

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

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

Какие бывают методологии, как они влияют на процесс разработки ПО и зачем они вообще нужны? В книгу включены крайне интересные приложения: программирование как построение теорий, применение языковых игр Витгенштейна к разработке ПО, применение методов Мусаши (самурай, живший в 17 веке и написавший книгу "Книга пяти колец") к разработке ПО.

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

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

Для управляющих проектами (Project Manager) и лидеров групп (Team Leader) книга из категории must read. Ваша эффективность, как руководителя, заметно возрастет.

Если говорить о качестве издания, то перевод достаточно хорош, за исключением термина agile. Единственный минус книги - плохая полиграфия, что не редкость для компьютерной литературы. Что удивительно, цена книги при таком качестве тоже не маленькая.

Книгу Алистера Коберна "Быстрая разработка программного обеспечения" можно приобрести в интернет-магазине www.rodina.by (www.rodina.by/book/info/go/6047.html).

Михаил ДУБАКОВ