К сожалению, не существует универсального процесса разработки ПО, полностью подходящего под каждый проект. Во главе угла стоят методологии – системы стандартов, содержащие понятия, методы и способы, которые определяют стиль создания программного обеспечения.
Методология подбирается, во-первых, под конкретные задачи, объемы работ, цели заказчика и бюджет. Во-вторых, не забываем и про специфику деятельности IT-компании. Техподдержка, аутсорсинг и внутренняя разработка своего проекта предполагают разные подходы.
Одни из самых распространенных категорий моделей разработки ПО – Agile и Waterfall, гибкая и каскадная соответственно. Мы дадим краткое описание каждой, рассмотрим их плюсы, минусы и определимся с корректной системой под проект.
Гибкие методологии придерживаются итеративных принципов разработки. Процесс создания продукта делится на серию коротких циклов по 1-4 недели. Каждая итерация представляет собой отдельный проект с планированием, проектированием, программированием, тестированием и ретроспективой.
При оплате труда разработчиков в рамках Agile обычно выбирают между выделенной командой под проект (Dedicated Team) и системой Time&Materials (T&M). Мы уже сравнили между собой некоторые механизмы построения финансовых отношений с подрядчиком. Наши выводы с позиций клиентов и разработчиков можно найти .
Гибкая модель разработки основана на 12 принципах, из которых определяющими мы считаем следующие:
К классу Agile относятся такие методики, как экстремальное программирование (XP), FDD, DSDM, Scrum и другие.
Waterfall
Принцип каскадной системы состоит в последовательности. Процесс разработки разбит на следующие шаги:
1. Анализ требований
2. Планирование
3. Реализация
4. Интеграция
5. Тестирование
7. Поддержка
Переход к каждой фазе происходит только после окончания предыдущей. Новые функции добавляются уже после релиза и исправления предыдущих ошибок. Благодаря четкой документации и стабильным требованиям для каскадных проектов лучше подойдет модель финансового взаимодействия с фиксированной ставкой (Fixed price).
А теперь сравним сильные и слабые стороны Agile и Waterfall.
Плюсы методологий:
Гибкая модель
Каскадная модель
Минусы методологий:
Гибкая модель
Каскадная модель
Изучив матчасть, мы легко научимся жонглировать Agile и Waterfall в своих проектах!
Гибкая модель разработки действует, если:
1. В проекте задействована опытная команда.
2. Окончательный функционал продукта пока неизвестен, и изменения необходимо вносить максимально оперативно.
3. Конечный пользователь «варится» в проекте с самого начала.
4. Необходимо быстро разработать рабочее ПО.
5. Вы стартап.
Выбирайте каскадную модель в случаях, если:
1. Требования к проекту стабильны и практически неизменны;
2. Качество продукта намного важнее затраченного времени и ресурсов;
3. Проект разрабатывается на аутсорсе;
4. Конечный пользователь только принимает результат работы, не участвуя в процессе.
Необходимо сказать, что обе модели помогут реализовать ваш проект. В первую очередь вы выбираете вариант, который позволит вам делать качественные продукты и эффективно управлять своим бюджетом.
Конечно, как только вы на финишной прямой, никого не будет интересовать выбранная методология. Поэтому, даже если модель разработки оказалась неподходящей, команда должна быть достаточно сильной для получения достойных результатов.
А теперь просто идите и сделайте свой проект!
Методология разработки софта - организация труда, включающая идеологические принципы, план, контроль над процессами, подход к сотрудникам. Выделим 12 видов:
Давайте попробуем разобраться, что скрывается за этими английскими названиями.
Модель Waterfall относится к классическому пониманию разработки ПО. Весь процесс является жестким и линейным, имеет четкие цели для каждого этапа, новая фаза начинается по завершению предыдущей, нет возврата назад. Преимущества водопадной методологии - децентрализация и строгий контроль над сроками и качеством исполнения.
На практике Waterfall часто не оправдывает ожиданий, поскольку игнорирует динамические изменения. Так, после тестирования очень сложно откатить процесс и заложить функции, не учтенные на стадии разработки. Waterfall неэффективен ещё и потому, что предполагает временные простои сотрудников в рамках одного проекта. Тестирование проводится только в конце разработки, хотя проблемы, найденные на этом этапе - это дорогостоящие исправления.
RUP - итеративный подход, который решает проблемы, которые есть у Waterfall. Чем хорош RUP:
Agile - метод гибкой разработки программного обеспечения, предполагающий большое количество итераций. Документ Agile Manifesto описывает 4 идей и 12 принципов гибкого подхода, коротко его можно описать всего двумя пунктами:
Несмотря на недостатки, Agile стала фундаментальной концепцией для разработки ПО и нашла отражение в других методологиях, речь о которых пойдет далее.
Методология, созданная для небольших коллективов из 6−10 сотрудников. Также поддерживает принципы гибкой разработки, но имеет чуть больше конкретики. Основная идея, которая и заключена в названии - каждая команда является набором людей с разным уровнем знаний, разными умениями и опытом.
Именно поэтому нет универсального подхода для разработки софта, он должен определяться в процессе общения внутри группы. Там же назначаются роли, инструменты, стандарты. Затем группа принимается за единицу и те же самые вопросы решаются на уровень выше, пока иерархия не дойдет до заказчика.
Модель спирального жизненного цикла - это сложная организация жизненного цикла ПО, которая фокусируется на раннем выявлении и уменьшении проектных рисков. Разработка начинается в небольшом масштабе, решаются локальные задачи, оцениваются риски и пути их уменьшения. Следующий шаг охватывает более комплексные задачи - следующий виток спирали.
Преимущество подхода не в увеличении скорости разработки, а в снижении уровня возникновения рисков. Успешность спирального метода зависит от добросовестного, внимательного и компетентного управления, а размер проекта не имеет принципиального значения.
Модель развития динамических систем была разработана в Великобритании в середине 1990-х годов и является эволюционным развитием быстрой разработки приложений (RAD). Основная идея стандартная: при планировании в самом начале невозможно понимать всех тонкостей разработки, поэтому весь процесс - исследовательская работа.
В DSDM тоже присутствует деление на команды, в каждой из которых есть уполномоченный для принятия стратегических решений. В процессе могут участвовать все заинтересованные стороны: пользователи, разработчики, заказчики, руководители. Тестирование проводится на протяжении всего жизненного цикла.
FDD - процесс для обеспечения масштабируемости и повторяемости, при этом поощряющий творчество и инновации. Вот основные принципы:
FDD регламентирует время, которое должно затрачиваться на каждый из процессов. Организационной деятельности в цикле должна занимать не более 23−25%, в то время как на непосредственную разработку, сборку и тестирование функций необходимо тратить 75−77% времени.
JAD - это методология, нацеленная на максимальную занятость в разработке конечного пользователя. Происходит это посредством встреч и проведения совместных семинаров. JAD была придумана в 1970-х годах сотрудниками IBM и нацелена на бизнес в целом. Однако со временем данная концепция стала успешно применяться и для разработки программного обеспечения.
В отличие от подхода Waterfall, JAD приводит к сокращению времени разработки, большей удовлетворенности клиентов и экономии средств на изучении рынка. С другой стороны, это требует большой клиентской выборки и необходимости разработчиков работать не со строгими требованиями ТЗ, а с постоянно меняющимся мнением.
RAD - методология, которая во главу угла ставит скорость и удобство разработки. Одно из главных условий - использование языка быстрой разработки. Это название абстрактного языка программирования, с помощью которого программист способен решать задачи быстрее, чем с представителями третьего поколения (C / C ++, Pascal или Fortran). Вот ещё несколько пунктов концепции:
RAD предполагает использование целого комплекса инструментов помимо языка быстрой разработки: системы сбора требований, среды разработки, фреймворки, программы для группового общения, ПО для тестирования.
Scrum - гибкий метод управления проектами, целью которого является повышение производительности труда в командах, ранее парализованных более тяжелыми методологическими процессами. В основе концепции лежат «спринты». Спринт - короткая итерация, строго ограниченная по времени (обычно 2−4 недели). В это время минимизируется длительность совещаний, но увеличивается их частота (они называются «схватками»).
Благодаря этому контроль за выполнением становится более гибким, а разработчики быстрее реагируют на возникающие проблемы. Традиционное планирование отходит на второй план, его место занимает журнал спринтов.
Экстремальное программирование - возможность вести разработку в условиях постоянно меняющихся требований. Вот несколько признаков:
Бережливая разработка ПО - ещё одно ответвление гибкой методологии, предполагающее сохранение высокого морально-функционального состояния разработчиков. Это выражается в:
В условиях короткого дайджеста трудно раскрыть все преимущества и недостатки методологий, показать эффективные области применения. О наиболее актуальных на сегодняшний день концепциях мы поговорим отдельно. О каких именно? Оставляйте свои пожелания в комментариях.
Разработка программного обеспечения не похожа на традиционные инженерные науки. Методология — это то, что используется разработчиками, чтобы разбить работу на управляемые прогрессивные этапы, где каждый из них может быть проверен для обеспечения качества. Команды работают вместе с заказчиком над созданием готового программного продукта при помощи одной из методологий разработки программного обеспечения. Наиболее популярными из них считают спиральную, водопадную, или каскадную модель (Waterfall); RAD, или быструю разработку приложений; Agile Model, или гибкую и итеративную, или итерационную модель. Существуют и другие варианты, но в этой статье рассмотрим только водопадную, или каскадную, модель а также исследуем ее преимущества и недостатки. Сразу же поясним, что она представляет собой последовательность определенных шагов, и ее особенность в том, что новый этап невозможен, пока предыдущий не был завершен.
Методология в ее традиционной форме почти не оставляет места для неожиданных изменений. Если команда разработчиков не слишком велика, а проекты - предсказуемы, то Waterfall может обеспечить их выполнение в заданных временных рамках.
Водопадная модель разработки существует уже более сорока лет. Она была впервые описана в 1970 году в статье У. Ройса как одна из самых первых официальных моделей для процесса разработки. Она описывалась как неэффективная для крупных проектов по разработке программного обеспечения, но никто не запрещал использовать ее для небольших. Почти полвека спустя после того, как она была открыта, эта методика все еще имеет значение в современном деловом мире. Ее называют устаревшей моделью и относятся с некоторым пренебрежением из-за устаревания традиционного проектного подхода к управлению. Но Waterfall является полезным и предсказуемым подходом, если требования фиксированы, хорошо документированы и ясны, если технология понятна и когда реализация проекта не занимает много времени. В этом случае каскадная модель может обеспечить более предсказуемый конечный результат для определенного бюджета, сроков и объема работы.
Модель Waterfall можно описать как линейное, последовательное развитие проекта, где процессы постоянно переходят от требований к проектированию, затем к реализации, проверке и развертыванию с последующим текущим обслуживанием. Считается, что каскадная модель жизненного цикла была создана благодаря У. Ройсу, хотя сам он использовал итеративную модель разработки.
Основной акцент в развитии по модели Waterfall делается на планировании, сроках, целях, бюджетах и в конечном счете реализации всей системы как единого объекта. Основные преимущества здесь заключаются в простом прямом и обратном планировании и внедрении.
По сравнению с другими методологиями, Waterfall больше других фокусируется на четком, определенном наборе шагов. Оригинальная модель состояла из пяти этапов. Часто она описывается как линейно-последовательная модель жизненного цикла. Это означает, что он следует простой структуре фаз, где результаты каждой фазы переходят на следующий уровень развития. Основные этапы - это:
Команды должны выполнить весь шаг, прежде чем перейти к следующему, поэтому, если что-то не готово к определенному сроку, это сразу становится заметным. А также, в отличие от Six Sigma или Scrum, Waterfall не требует сертификации или специального обучения для менеджеров проектов или сотрудников.
Каскадная модель жизненного цикла информационной системы была подвергнута критике из-за ее негибкости после завершения каждого этапа, а также из-за задержки возможности клиента обеспечить обратную связь. Тем не менее эта методология может хорошо работать в небольших проектах с ограниченным бюджетом. Ее часто сравнивают с одной известной методологией жизненного цикла проекта - PRINCE2, которая была создана правительством Великобритании. Эта методология до сих пор используется в государственном секторе. Одно из ключевых различий между PRINCE2 и каскадной моделью жизненного цикла заключается в том, что в последней необходимо описание в письменной форме всех требований с самого начала, ведь впоследствии их будет трудно пересмотреть. До того момента, как начнется создания любого кода, они должны быть точно определены и зафиксированы. Это важное преимущество каскадной модели жизненного цикла.
Поскольку техническая документация является необходимой частью этапа разработки первоначальных требований, это означает, что все члены команды ясно понимают цели проекта. Новые разработчики могут быстро разобраться в правилах создания кода и влиться в процесс работы без особых проблем. Если используется каскадная модель жизненного цикла информационной системы или проекта, поэтапное исполнение обеспечивает соблюдение дисциплины.
Каждый шаг имеет четко определенную отправную точку и вывод, благодаря чему легко контролировать прогресс. Это помогает уменьшить любое уклонение выполнения проекта от согласованных временных рамок. В этой модели, в отличие от спиральной, программное обеспечение рассматривается как единое целое. Поэтому, при условии выполнения всех требований, она работает более эффективно. Если продолжить сравнивать каскадную и спиральную модель жизненного цикла, то можно сделать вывод, что первая более универсальна и может применяться в различных сферах.
Также плюсом каскадной модели жизненного цикла является то, что затраты могут быть оценены с довольно высокой степенью точности, после определения всех требований. Если она применяется, значит, что на первом этапе все тестовые сценарии уже подробно описаны в функциональной спецификации, что делает процесс тестирования более простым и прозрачным. А также еще до начала разработки программного обеспечения детально прорабатывается дизайн, что делает потребности и результат понятным для всех.
Одним из важных плюсов при использовании Waterfall является стремление к конечному продукту, или конечному результату, с самого начала. Поэтому команды должны избегать отклонения от цели. Для небольших проектов, где намерения достаточно ясны, этот шаг делает команду осведомленной об общей цели с самого начала, из-за чего снижается шанс заблудиться в деталях по мере продвижения проекта вперед. Подход Waterfall очень методичен, поэтому он подчеркивает важность чистой передачи информации на каждом этапе. В процессе разработки программного обеспечения, на каждом новом шаге появляются новые люди. Поэтому важно стремиться к тому, чтобы документировать информацию на протяжении всего жизненного цикла проекта.
Потенциальные проблемы развития могут быть исследованы и решены на этапе проектирования. Альтернативные решения также прорабатываются и выбираются оптимальные. Все это происходит до начала реализации проекта. Многие организации ценят внимание к документации в самом начале, так как это также означает, что не должно быть сюрпризов с конечным продуктом. Но на практике редко получается обойтись без внесения правок. Клиентам часто бывает трудно осмыслить собственные потребности, оперируя лишь понятиями функциональной спецификации на этапе формирования требований. Это означает, что они могут изменить свое мнение, как только увидят конечный продукт. Такую проблему сложно решить. Иногда приложение приходится перерабатывать практически полностью.
Еще одним минусом каскадной модели жизненного цикла ИС (или проекта) является потенциальное отсутствие гибкости. Могут возникнуть вопросы, связанные с учетом новых изменений или изменения требований, которые произошли после первоначальных консультаций.
Корректировки, вызванные бизнес-планами или влиянием рынка, возможно, не были приняты во внимание при планировании. Также реализация проектов может занять больше времени по сравнению с использованием итерационной методологии, такой как Agile.
Когда дело доходит до разработки Waterfall, очень важно, чтобы разработчики программного обеспечения могли эффективно направлять и консультировать клиентов, чтобы позже обойти все эти проблемы. Часто самый критичный аспект применения каскадной модели жизненного цикла - то, что клиенты действительно не знают, чего они хотят на самом деле. Во многих случаях подлинное двустороннее взаимодействие между разработчиками и клиентами не происходит до тех пор, пока клиент не увидит модель в действии.
Для сравнения, в Agile development клиент может увидеть фрагменты рабочего кода, которые были созданы в процессе работы над проектом. В отличие от Scrum, который делит проекты на отдельные спринты, Waterfall всегда фокусируется на конечной цели. Если у вашей команды есть конкретная цель с четкой конечной датой, Waterfall устранит риск не уложиться в срок, когда вы будете работать над ней. Исходя из этих плюсов и минусов, разработка Waterfall обычно рекомендуется для проектов, которые, скорее всего, не изменятся либо нуждаются в новых разработках в течение жизненного цикла проекта.
Противостояние Agile и Waterfall не столько теоретическое, сколько практическое. Выбор методики, не подходящей под ваш проект, в лучшем случае существенно затормозит его развитие, в худшем — отправит в список «ТОП-провалов года».
Гибкая и каскадная модели разработки проекта (Agile и Waterfall соответственно) — одни из наиболее популярных среди прочих методологий управления. Изучив особенности конкретно вашего проекта, и вооружившись знаниями из этой статьи, вы сможете с полной уверенностью ответить на вопрос: «Что подойдёт моему бизнесу — Agile или Waterfall?»
Как и другие популярные методологии разработки и управления проектами, Agile появился сравнительно недавно в США. В отличии от CPM и CCPM, за появление гибкой методологии разработки ответственна сразу целая группа людей — 17 американских IT-специалистов из штата Юта. Вместе с «Манифестом гибкой разработки ПО», в котором впервые прозвучал термин «Agile» они прописали 12 принципов Agile-разработки.
Методика Waterfall (водопадная система разработки) — детище Винстона Уолкера Ройса, директора Lockheed Software Technology Center в Остине (штат Техас, США), пионера в области разработки программного обеспечения.
С методикой Waterfall получилось также, как и с многими изобретениями: свой вклад в создание методологии сделали Герберт Беннингтон в 1956 г. и Хозьер в 1961 г., а Уолкер использовал их наработки, обеспечив себе славу «создателя Waterfall». Победителей не судят...
Водопадная модель разработки подразумевает последовательное прохождение процесса, разбитого на стадии. Переход к новому этапу возможен только после завершения предыдущего.
Компания Toyota, популяризовавшая методологии Lean и Kanban, до конца 2000-ых пользовалась каскадной моделью разработки ПО для нужд производства.
Частично недостатки водопадной модели разработки исправлены в модификациях Waterfall: Сашими, Waterfall с субпроектами и водопадная модель разработки с снижением риска.
Waterfall с субпроектами — модель, в которой вы работаете с трёмя крупными блоками: концептуализацию, проектирование требований и архитектурная структура продукта. Затем для каждого из них вы проходите стадии (субпроекты) детального проектирования, кодирования и тестирования. В конце проводится интеграция всех компонентов на этапе тестирования системы.
Waterfall |
||
Суть | Гибкая модель разработки, основанная на | Каскадная система разработки, основанная на жёсткой последовательности процесса разработки |
Дата создания | 1956 г., 1961 г., 1970 г. |
|
Разработчики | Группа IT-специалистов (США) | Г. Беннингтон, Хозьер, В. Уолкер Ройс |
Принципы применения |
|
|
Плюсы |
|
|
Минусы |
|
|
Компании-практики | Unilever, ряд банков (Альфа Банк, Home Credit, Райффайзен Банк и т.д.) | Cisco Ericsson AB, Toyota (до 2010) |
Подойдёт вам, если... |
|
|
Не подойдёт, если... |
|
|
Agile и Waterfall — две абсолютно разные методики разработки и управления проектами. Каждая из них породила десятки модификаций и методов, «заточенных» под конкретный формат проектов.
С учётом особенностей каждой из методик и вашего бизнеса, а также на основе критериев риска, времени и вовлечения заинтересованных лиц вы сможете самостоятельно определить эффективную методологию.