Методы «быстрой» разработки программной системы: методология Agile, методология экстремального программирования XP

Постоянное участие заказчика (on-site customer). Представитель заказчика непрерывно находится в команде разработчиков в период работы над системой. При этом требования к квалификации этого человека группы из нескольких человек весьма высоки. Если заказчик не согласился предоставить высококвалифицированный персонал уровня экспертов, то проект попадает в группу наиболее высокого риска.

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

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

Частая смена версий (small releases). Систему вводится в эксплуатацию уже через несколько месяцев после начала работы над проектом, не дожидаясь окончательного разрешения всех поставленных проблем. Периодичность выпуска новых релизов может варьироваться от ежедневной до ежемесячной. Протестировать за такой срок более-менее сложный компонент информационной системы не представляется возможным. В роли тестера в данном случае выступает заказчик. Системы, к которым предъявляется требование непрерывной надежной работы — так называемые системы уровня 24/7 — входят в группу наибольшего риска.

Переработка системы (refactoring). Архитектура системы постоянно развивается. Текущий проект трансформируется, при сохранении гарантированного правильного выполнения всех тестов. Экстремальное программирование исходит из следующие предпосылки. Переделка части системы всегда возможна без привлечения особых затрат. Вместе с тем практика внедрения XP говорит о том, что возникающие при этом риски могут во много раз превышать преимущества от внедрения данной методологии.

Непрерывная интеграция (continuous integration). Новая кодовая база интегрируется в существующую систему не позднее чем через несколько часов. После этого код компилируется и собирается для внедрения в систему. Следующим этапом является прогон всех тестов. Если хотя бы один из тестов не выполняется корректно, внесенные изменения откатываются. В данном случае не всегда понятно, кому поручить исправление ошибок, причем не только локальных, но и ошибок, появившихся вследствие включения неправильного кода. Проведение комплексных тестов на данном этапе не предполагается. Кроме того, хорошей практикой является сохранение изменений даже в случае обнаружения заведомой ошибки.

Программирование в паре (pair programming). Весь код проекта пишут группы по два человека, использующих одно рабочее пространство. Человеческий фактор в данном случае играет определяющую роль. Пара работает результативно только в случае, если оба члена команды правильно выполняют свое дело.

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

Коллективное владение (collective ownership). Каждый разработчик имеет возможность при необходимости в любое время усовершенствовать любую часть кода в системе. Без жесткого контроля исходного кода процесс разработки приобретает абсолютно неконтролируемый характер.

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

Методология разработки информационных систем уровня предприятия находится на стадии своего становления как отдельной области исследований, о чем свидетельствует появление отдельной дисциплины, под названием программная инженерия. Существующие попытки стандартизировать подходы к разработке программных систем объединены в несколько успешных стандартов и регламентов, определяющих прядок работ на всех этапах ЖЦ. Данные стандарты различаются между собой по области применимости. Каждый подход имеет право на существование и содержит множество примеров, когда проект завершился успешно или неуспешно.

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ Липаев В. В. Программная инженерия. Методологические основы. — М: ТЕИС, 2014. — с. 112.

Орлов С. А. Технологии разработки программного обеспечения. — СПб.: Питер, 2014. — с. 435.

Котляров В. П. Основы тестирования программного обеспечения. — М.: БИНОМ. Лаборатория знаний, 2016. — с. 376.

Шафер Д, Фатрел Р, Шафер Л. Управление программными проектами: достижение оптимального качества при минимуме затрат. — М.: Вильямс, 2017. — с. 689.

Новикова Г. М. Основы разработки корпоративных инфокоммуникационных систем. — М.: РУДН, 2017. — с. 243.

Стеллман Э. Постигая Agile. — М.: Манн, Иванов и Фербер (МИФ), 2017. — с. 98.

Сазерленд Дж. Scrum. Революционный метод управления проектами. — М.: Манн, Иванов и Фербер, 2016. — с. 873.

Пихлер Р. Управление продуктом в Scrum. Agile-методы для вашего бизнеса. — М.: МИФ, 2017. — с. 467.

Андерсон Д. Канбан. Альтернативный путь в Agile. — М.: МИФ, 2017. — с. 125.

Богданов В. Управление проектами. Корпоративная система — шаг за шагом. — М.: МИФ, 2014. — с. 287.