Анна Сергеева. Гибкие методологии разработки современных программных приложений // Системный администратор. 2015. № 1-2. С. 82-85.
Краткий обзор наиболее распространенных стандартных гибких методологий, успешно применяемых в разработке современных программных приложений разных уровней сложности. Взгляд автора на преимущества и недостатки при практическом использовании.
Опубликовано в разделе "Разработка / Инструменты"
Эта же статья на сайте журнала
В современном мире создание программ, которые служат для удобного и быстрого решения всевозможных профессиональных и персональных задач, — это всегда бизнес.
И рост и расширение этого бизнеса напрямую зависит от привлечения новых клиентов, поддержки существующих и удовлетворения их часто меняющихся высоких запросов. То есть, ответственный производитель должен гарантировать своевременное и непрерывное предоставление работоспособного ПО, которое будет подстраиваться под потребности конкретных клиентов, соответствовать мировым тенденциям по набору и объему реализуемых функций, а также по стоимости этого ПО для клиентов.
С другой стороны, разработка ПО — это взаимодействие команды разработчиков и тестировщиков, их руководителей, заказчиков и конечных пользователей.
И если крупная корпорация работает на собственном капитале, то сроки выпуска продукта не так критичны (неделя плюс, неделя минус для них не существенны). В отличие от них, для относительно небольших компаний, которые работают на заемном капитале, сроки поставки готового ПО имеют особую важность. Ибо прибыль возможна только в результате продаж продукции, а кредитные обязательства компании перед заимодателем никто не отменял.
Значит, для финансового успеха нужно организовать процесс разработки так, чтобы минимальными усилиями в сжатые сроки добиться выпуска и поставки требуемого конкурентоспособного продукта [1].
Соответственно, руководство компаний разработчиков ПО сталкивается с необходимостью максимально эффективно организовать процесс своей внутренней работы.
В настоящее время существует достаточно большой выбор методологий, подходящих для внедрения в самые разноплановые проекты разработки программного обеспечения (ПО). Многие из них достаточно давно и широко используются в мировой практике, получили большое развитие и популярность.
Предлагаю ознакомиться с наиболее распространенными методологиями и выбрать наиболее подходящую для организации и управления конкретным разрабатываемым программным проектом. При этом грамотный и внимательный руководитель проекта разработки ПО, скорее всего, будет брать за основу наиболее интересные, на его взгляд, ключевые особенности той или иной стандартной, общепризнанной методологии и дополнит ее собственными методами, полученными в результате личного профессионального опыта. Итак, начнем.
Основные принципы гибких методологий (Agile)
В последние годы широкой популярностью пользуются именно гибкие методологии разработки ПО. Их общая концепция — эффективная и, вместе с тем, достаточно демократическая организация взаимодействия небольших групп разработчиков и минимизация рисков за счет развития проекта на базе серии коротких циклов (итераций).
Вот 12 основополагающих принципов, входящих в так называемый «Манифест гибкой методологии разработки программного обеспечения» [2]. Перечислим их кратко.
1. Первоочередной целью команды разработчиков является удовлетворение требований заказчика, для чего предусматривается ранняя и непрерывная поставка работоспособного программного обеспечения.
2. И такое работоспособное программное обеспечение необходимо выпускать достаточно часто (от интервала в неделю до раза в несколько месяцев). При этом, наиболее предпочтительными являются самые короткие интервалы.
3. На протяжении всего проекта взаимодействие разработчиков и представителей заказчика должно быть постоянным, для согласования меняющихся требований и уточнения деталей.
4. Стоит заметить, что меняющиеся требования заказчика приветствуются даже на заключительных этапах разработки. Ведь в рамках идеологии Agile изменения — это возможность обеспечить заказчику высокие конкурентные преимущества.
5. В идеале, проект должен развиваться с постоянной скоростью. Разработчики, пользователи и заказчики проекта должны быть способными к поддержанию постоянной скорости, и не сбавлять темпы с течением длительного времени.
6. Самый эффективный способ для передачи существенной информации о проекте группе разработчиков — это неформальное живое общение участников. Точно так же организуется общение и уже внутри самой группы разработчиков.
7. Необходимо для всех участников проекта обеспечить достаточно высокую мотивацию. Предоставить рабочую среду, доверить самостоятельное выполнение поставленных рабочих задач, обеспечить поддержку, которая им требуется, и поощрение положительных результатов.
8. В качестве главного показателя прогресса проекта выступает работоспособное программное обеспечение.
9. Самоорганизующиеся команды предоставляют самые лучшие требования к проекту, его архитектуру и дизайн.
10. Существенный фактор простоты реализации — грамотное определение и максимизация избыточных работ (нет смысла тратить время на труд, в котором нет необходимости).
11. Значительно повышает степень гибкости разработки непрерывное внимание, уделяемое хорошему дизайну и техническому совершенству.
12. Для повышения эффективности и улучшения процесса работы команды планируется периодический регулярный анализ своих действий.
Подытоживая вышесказанное, можно говорить о том, что Agile ориентируется, в основном, на минимальную формализацию и итеративную разработку проектов.
На сегодняшний день, методологий, которые можно причислить к разряду гибких, существует достаточно большое количество [3]. В статье рассмотрим только наиболее известные и активно развивающиеся.
Extreme Programming
Экстремальное программирование — это одна из наиболее известных гибких методологий. Вот ее основные принципы.
В первую очередь, это достаточно простой дизайн, а также применение стандартов кода. Это, в свою очередь, помогает более легко организовать процессы парного программирования и коллективного владения кодом.
Вместе с тем, поддерживается так называемая игра в планирование (то есть, планирование не прерывается вплоть до полного завершения работ над проектом) и короткие релизы.
Вместо детального планирования процесса разработки ПО большое внимание уделяется роли заказчика продукции. Предполагается, что он находится в постоянном контакте с группой разработчиков и готов отвечать на возникающие у них вопросы касательно нюансов реализации.
Касательно формализации разработки, как правило, она ограничивается сопровождением кода подробными комментариями. За счет этого значительно сокращается время разработки, что в свою очередь позволяет снизить и общую стоимость разработки. Однако, стоит внимательно относиться комментированию кода и не пренебрегать им. Иначе, при перераспределении задач между несколькими исполнителями или в случае ротации кадров может возникнуть путаница в понимании кода или даже частичная потеря информации - для чего предназначен тот или иной блок кода и как это должно работать.
А вот тестирование, напротив, проводится довольно тщательное, ему уделяется достаточно много внимания. Практически для каждого модуля программы предусмотрен набор тестов, которые повторно исполняются после каждого изменения кода, и так на протяжении всего проекта. Этот подход иначе называется «разработкой через тестирование» (Test-Driven Development, TDD). Здесь на помощь приходит автоматизация тестирования: во избежание рутины, для более достоверного получения результатов тестов (автоматизация гарантирует одинаковое исполнение одних и тех же тестов при каждой итерации), а также для сокращения времени работы и сил, затраченных на нее тестировщиками.
Также упор делается на постоянный рефакторинг кода (то есть, переработке и реорганизации внутренней структуры кода без изменения внешнего поведения программы — для лучшего понимания ее работы).
Scrum
Эта методология, в основном, ориентирована на относительно небольшие (в пределах десятка человек) группы разработчиков.
Полный проект разбивается на отдельные итерации (иначе называемые спринты) длительностью около 30 дней. Определяется перечень тех функций, реализация которых планируется в течение ближайшего спринта.
Здесь важно соблюдать такие условия. На протяжении одного спринта не менять список функций, одобренных к реализации. Плюс, срок выпуска очередного релиза должен строго соблюдаться, даже если к этому моменту реализовать удается не все функции.
Ежедневно руководитель проекта разработки проводит короткие (менее получаса) совещания, где составляет список реализованных за предыдущий день функций, определяет возникающие сложности разработки, а также составляет план работ на следующий день.
При такой организации совещаний можно очень удобно и эффективно непрерывно отслеживать ход работ над проектом, оперативно выявлять проблемы и тут же реагировать на них. Разумеется, от руководителей здесь требуются навыки быстро анализировать текущую ситуацию, и сохраняя общий курс проекта, вырабатывать наиболее удачные решения и быстро и доходчиво разъяснить новые требования исполнителям. А разработчикам, в свою очередь, нужно, не теряя самообладания, привыкнуть легко адаптироваться к подобным постоянным изменениям и прекрасно осознавать, что они есть не следствие импульсивности руководителей, а призваны повышать эффективность прохождения разработки и работают на успех общего дела.
Kanban
В отличие от предыдущих, данная методология предлагает совершенно другой способ распределения рабочих задач.
Здесь назначение рабочих задач выполняют не руководители проекта, а сами разработчики. При этом следует учитывать, что каждый разработчик в состоянии обрабатывать ограниченное число задач.
За счет такой самоорганизации длительность разработки может сократиться весьма значительно. Однако, в силу определенных причин, воспользоваться всеми плюсами данной методологии в состоянии далеко не каждый коллектив разработчиков. Следует учитывать, что почти в каждой команде есть участники, способные бесстрашно взять на себя более сложные и критичные задачи, есть и те, кто просто рожден в самые сжатые сроки решать большое число небольших разноплановых задач, оперативно переключаясь с одной на другую, но также могут найтись и такие, кто способен справиться лишь с теми несколькими задачами, что оставят им остальные... Руководству, скорее всего, нужно присмотреться к «темпераменту» разработчиков, обязательно поощрять успешную работу конкретных лиц, и, основываясь на специфике конкретного проекта и на объеме и характере задач, соблюсти, в конце концов, необходимые пропорции в составе участников проекта.
Feature Driven Development (FDD)
FDD – это функционально-ориентированная методология разработки. В этом случае, разработка проходит 5 ключевых этапов:
-
Создание общей модели системы.
-
Определение перечня требуемых функций системы.
-
Составление плана работ по каждой из функций.
-
Формирование архитектуры функций.
-
Работы по реализации функций.
Для данной методологии характерна итеративная модель жизненного цикла с достаточно частым выпуском новых версий, в каждой из которых реализован определенный небольшой перечень функций. Разделение работ и их координация выполняются на этапах составления плана работ и формирования архитектуры функций.
Основное достоинство методологии FDD — это изначальная поддержка больших команд разработчиков, в которых отдельные функции реализуются небольшими группами, возглавляемыми ведущим разработчиком.
Crystal Clear
Эта методология интересна тем, что позволяет варьировать степень формализации процесса разработки с учетом числа исполнителей и критичности стоящих перед ними задач. Она несколько уступает в производительности методологии Extreme Programming, но гораздо проще в использовании.
Предназначается она, скорее, для разработки некритичных бизнес-приложений силами совсем небольших команд (6-8 человек). Как это и присуще всем гибким методологиям, Crystal Clear делает больший упор на людей, нежели на процессы.
Весь проект разбивается на итерации, разработка ведется в инкрементальном режиме. В большинстве случаев, при работе с кодом используются инструменты контроля версий. Большое внимание уделяется автоматизации регрессионного тестирования. Также предусматривается активное взаимодействие с пользователями (обратная связь), а документация формируется самими участниками производственного процесса.
Как правило, если руководство того или иного проекта не определилось с выбором конкретной методологии разработки, доверяет своим достаточно квалифицированным работниками и ориентируется на тот стиль работы, к которому они привыкли, то так или иначе методология Crystal Clear устанавливается естественным образом.
Rational Unified Process (RUP)
ДаннаяметодологияразработкиПОбыласозданавкомпанииRational Software. Последователям идеологии Agile данная методология показалась достаточно перспективной, и они выпустили ее упрощенную версию — Agile Unified Process (AUP), которая содержит описание простой и понятной модели для создания программных бизнес-приложений.
В основу легли следующие принципы.
Для проекта используется компонентная архитектура, которая реализуется и тестируется на самых ранних этапах разработки. Соответственно, архитекторам проекта отводится ведущая роль в работе сплоченной команды разработчиков.
Также большое внимание уделяется выполнению требований, которые заказчики выдвигают к реализуемому ПО. А значит, изменения требований и деталей реализации ожидается на всех этапах процесса разработки.
И, конечно, подразумевается раннее обнаружение и оперативное устранение любых возможных возникающих рисков, а также непрерывное обеспечение качества разработки на всех этапах развития проекта.
Основная особенность методологии заключается в том, что в зависимости от требований проекта может варьироваться степень формализации. Таким образом, по завершении каждого из этапов проекта можно создавать полный объем требуемой документации, достигая максимальной формализации. А можно поступить и совсем наоборот, создавая только необходимый минимум рабочих сопроводительных документов, или же не создавать их вовсе.
Такой подход к формализации процессов позволяет добиться очень высокой гибкости методологии и сделал ее широко популярной. Она одинаково успешно применяется как в больших комплексных проектах, в которых просто необходима высокая степень формализма, так и в малых быстрых проектах, в которых отсутствие лишней формализации позволяет сократить расходы и время разработки.
Вот почему при использовании данной методологии одна и та же команда разработчиков может реализовывать проекты, сильно различающиеся по сложности и объему требований.
* * *
Возвращаясь к истории возникновения гибких методологий, следует сказать, что создавались они в первую очередь для продуктов, с постоянно меняющимися на всех стадиях требованиями к разработке. Именно этим они принципиально отличаются от многих классических методологий, например, от каскадной модели, где для любых изменений в проекте необходимы долгие согласования.
Scrum получила наибольшее распространение и развитие. С ее ежедневными контрольными совещаниями, позволяющими непрерывно держать руку на пульсе событий и оперативно управлять курсом хода разработки в зависимости от текущей ситуации. Демократичная в своем роде Kanban дает определенно больше свободы, позволяя разработчикам самим выбирать задания. Crystal Clear с ее простотой и удобством организации процессов подходит даже для самых небольших команд. И Feature Driven Development, которая, напротив, так хороша для крупных проектов с большим числом участников. И многие другие.
И как же в целом сказывается такой фактор как непрерывная корректировка требований на протяжении всего жизненного цикла проекта?
Конечно, нельзя не согласиться с таким общим основным минусом всех гибких методологий как невозможность достаточно точно оценивать сроки и бюджет разработки. Но, при всем при этом, достоинства способны перевешивать подобные недостатки.
К несомненным важным плюсам стоит отнести короткие сроки разработки и выпуска готового продукта, а также практически полное отсутствие простоев во время согласования проектной документации.
Литература
1 Вумек Джеймс П., Джонс Даниел Т. Бережливое производство. Как избавиться от потерь и добиться процветания вашей компании. — М.,: Альпина Паблишер, 2011. – 487 с.
2 Криспин Л., Грегори Дж. Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд. — Вильямс, 2010. – 464 с.
3 Вольфсон, Б. Гибкое управление проектами и продуктами. – Питер, 2015. – 144 с.