Вступление
Как выбрать методологию? Зачастую, когда необходимо принять решение о выборе методологии в голове слишком много разнородной информации и тяжело понять, что именно лучше подойдёт для проекта. В данной статье я представляю блок-схему выбора оптимальной методологии, как некую подсказку, позволяющую обратить внимание на некоторые наиболее важные аспекты.
В первую очередь хочу отметить, что не бывает универсального набора условий для всех ситуаций при выборе той или иной методологии. В каждом случае вы должны ориентироваться на специфику своего проекта. Рассматриваемая блок-схема лишь обозначит главные аспекты и позволит вспомнить особенности основных методологий. Ни в коем случае не призываю относиться к ней, как к единственно правильному руководству по выбору методологии. Тем более не стоит распространять её на такие сложные проекты как создание ОС, авионики самолёта, моделирование ядерных реакций.
Во-вторых, выбрав методологию, не нужно слепо следовать ей. Часто ее необходимо «допилить», адаптировав под свой проект. Что-то можно выкинуть, что-то добавить из других методологий, внести что-то своё. Например, вам никто не мешает использовать такую практику как парное программирование в водопадной модели, если это принесёт вам пользу. На Хабре есть прекрасная статья по адаптации Скрама и Канбана к конкретному проекту, которая хорошо иллюстрирует данный принцип.
В следующей главе я очень кратко расскажу про упоминаемые в статье методологии и модели жизненного цикла, для тех, кто слышит о них впервые. Более подробно про каждую из них можно прочитать в Википедии. Если вы уже знаете их, то можете смело переходить к главе 2: «Разбор блок-схемы».
1. Краткое описание
Модель жизненного цикла – общее описание того, как происходит процесс разработки.
Методология – более детализированный набор правил, практик и принципов, как способ реализации той или иной модели. Например, методология Скрам реализует итеративную модель разработки.
Фреймворк процессов – грубо говоря, это методология, содержащая большое количество правил, но в которой необязательно использовать их все, а можно выбрать только то, что нужно и построить свой процесс разработки. Имеют в своём составе специальные приложения, позволяющие просматривать и редактировать правила. Примеры: RUP, EssUp.
Каскадная модель (или модель водопада, Waterfall) – характеризуется тем, что этапы разработки, такие как: анализ, проектирование, реализация, тестирование, идут друг за другом. Позволяет быстро создавать систему, без дополнительных накладных расходов на организацию процесса разработки. Однако она работает только тогда, когда требования стабильны и не меняются в ходе разработки, т.к. мы сразу описываем все требования, а потом сразу проектируем всю систему целиком.
V-Model — придумана в Германии и США, как способ улучшить каскадную модель для применения в государственных проектах. V-Model имеет специфику проектов для гос органов: фиксированные требования, стоимость и время. Отличие в том, что этап анализа и проектирования связан с этапом тестирования. Например, во время анализа требований одновременно изучаются подходы к тестированию, во время проектирования архитектуры системы разрабатываются высокоуровневые планы и сценарии тестирования, во время проектирования компонентов системы изучаются способы тестирования компонентов и их взаимодействия, создаются сценарии тестирования, пишутся утилиты, помогающие в тестировании, инструкции, скрипты и т.д. Всё это помогает лучше понять требования и спроектировать систему. Однако тут, также как и в каскадной модели, нежелательно, чтобы требования менялись во время разработки.
Спиральная модель (Spiral) – ориентирована на проекты, в которых имеются серьёзные риски. Разработка представляется в виде спирали. Каждый виток спирали – итерация. Виток спирали состоит из четырёх этапов: планирование, анализ рисков, разработка, оценивание заказчиком. В конце каждой итерации решается, стоит ли продолжать проект. Характерной чертой является то, что на этапе анализа рисков создаются прототипы, концепты, модели которые призваны разрешить риск на ранней стадии. Чем дальше движение по спирали, тем больше разработки продукта и меньше прототипов и концептов. Типичное применение такой модели – исследовательские проекты. Является очень дорогой моделью, и не оправдана в системах, где риски незначительны.
Итеративная модель – ориентирована на проекты, где требования могут меняться по ходу разработки. Проект состоит из итераций (от 1-2 до 6 недель). Каждая итерация может включать в себя этап анализа, проектирования, реализации, тестирования. Имеет большие накладные расходы на организацию процесса, чем каскадная модель, однако стоимость исправления ошибки в зависимости от длительности проекта не так высока. Следующие методологии реализуют итеративную модель: Scrum, XP, отчасти Kanban.
Методология Скрам (Scrum) – итерация называется спринтом. Команда состоит из 3 ролей: владелец продукта (представитель заказчика), скрам-мастер (следит за следованием процессу), остальные члены команды. Спринт начинается с митинга планирования, когда команда отбирает и распределяет задачи на итерацию, формируя бэклог спринта. Спринт заканчивается обзором спринта, где проводится демонстрация продукта и митингом ретроспективы спринта, на котором обсуждаются улучшения. Ежедневно проводятся 15-минутные скрам-встречи.
Методология экстремального программирования (XP) – состоит из 12 практик: парное программирование, разработка через тестирование, рефакторинг, простая архитектура, коллективное владение кодом, непрерывная интеграция, заказчик в команде, частые релизы, игра в планирование, 40-часовая рабочая неделя, стандарты кодирования, метафора системы. Обязательно использование всех 12 практик.
Методология Канбан (Kanban) – конвейер задач. Имеет всего 3 правила: визуализация процесса разработки с помощью канбан-доски, ограничение на количество задач на каждом этапе, постоянное измерение производительности команды и улучшения.
Методология RAD (Rapid Application Development) – ориентирована на быструю разработку приложения, итеративно, с максимально простой архитектурой, минимальными издержками на процесс, максимально используя готовые компоненты и мощные инструменты. Имеет ограничение на длительность проекта — 60-90 дней. Мне нравится аналогия с пирожками из полуфабрикатов. Так вот, RAD – когда нужно быстро слепить пирожок из готовых компонентов.
2. Разбор блок-схемы
Стартапы характерны тем, что там, особенно в начальный период, всё строится на энтузиазме. Далеко не всегда люди работают по 8 часов в день. Если им навязать какую то методологию и поставить в определённые рамки, то либо весь энтузиазм угаснет, либо никто не будет соблюдать правила. Например, довольно глупо ожидать, что инициатор стартапа придёт утром вовремя на скрам-митинг, после бурной ночи кодинга. В дальнейшем, когда всё стабилизируется, можно перейти к использованию подходящей методологии.
Каждый проект имеет риски. Однако в данном случае имеются в виду риски настолько серьёзные, что заранее не известно, можно ли будет вообще реализовать систему. Если такие риски присутствуют, то, скорее всего, вы начнёте разработку с прототипов, концептов, моделей и т.п. чтобы выяснить принципиальную возможность задуманного. В таком случае для вас наиболее оптимальной моделью будет спиральная модель. Типичный пример применения этой модели – исследовательские проекты. Но только исследовательскими проектами применение этой модели не ограничивается.
Пример из реальной практики в области розничной торговли: нам необходимо было разработать мобильное приложение, которое должно было активно взаимодействовать с определённым оборудованием по Bluetooth. Это были считыватели различных карт, различные виды принтеров и сканеры штрих кодов. Нам было не известно, возможно ли это вообще сделать на мобильной платформе. Поэтому мы начинали с прототипов и концептов, в которых пытались выяснить принципиальную возможность взаимодействия с оборудованием и существующие ограничения. Потом мы встречались с заказчиком, демонстрировали то, что получилось и обсуждали обходные пути для того, что не удалось реализовать.
Если же в вашем случае нет таких серьёзных рисков, то встаёт следующий вопрос: будут ли требования меняться. Если ваши требования заранее хорошо известны, и вы уверены что в процессе разработки заказчик не будет вносить сколь-нибудь существенные изменения, то тогда вам следует выбрать каскадную модель разработки. Я рекомендую выбирать каскадную модель, когда у проекта небольшая длительность. В случае чётких и неизменных требований вкупе с небольшой длительностью, каскадная модель в сравнении с итеративной моделью даст меньше накладных расходов на процесс. На всём этапе реализации программистов ничто не будет отвлекать от написания кода: ни необходимость срочно исправлять баги из прошлой итерации, ни бесконечные митинги и релизы.
Однако в случае длительных проектов, каскадная модель будет плохо работать. Несмотря на то, что риски изменения требований отсутствуют, присутствует технические риски. Например, если вы разработали некорректную архитектуру, выбрали не те технологии и инструменты, не рассчитали требуемую производительность и т.п., с большой долей вероятности вы узнаете об этом в конце, и времени на исправление может не остаться. Чем дольше длится проект, тем выше цена исправления ошибки. Если на начальном этапе рефакторинги и кардинальные изменения кода даются легко, то под конец проекта, сделать это уже довольно-таки «болезненно».
Пример из практики: нам необходимо было реализовать мобильное приложение, которое делало бы абсолютно то же самое, что и такое же приложение для настольного компьютера. Таким образом, требования были известными и неизменными на всём протяжении проекта.
Следующий вопрос: сложные ли требования. Вопрос опять-таки не однозначный и зависит от проекта. Кода вы начинаете проект, иногда бывает полезным на этапе анализа и проектирования продумать, как вы будете тестировать. Это может помочь раньше выявить потенциальные проблемы и лучше реализовать архитектуру, проработать требования и т.п. Когда требования сложные, рекомендуется тщательно продумать все сценарии тестирования, и ещё на этапе анализа и проектирования разработать подходы к тестированию, тест-планы и тест-кейсы. В таком случае нам приходит на помощь модель V-Model, являющаяся разновидностью каскадной модели.
Применение V-Model там, где требования достаточно простые приведёт к тому, что система окажется дороже. Более того V-Model критикуют за то, что она порождает множество документации и бюрократии и служит в реальности не для того, чтобы создать качественный софт, удовлетворяющий заказчика, а для того, чтобы в конце проекта доказать, что система работает как и требовалось изначально, вместо того, чтобы действительно разработать то, что ему было нужно.
Формализованный подход заключается в том, что все процессы жизненного цикла приложения детально регламентированы. Это необходимо в сложных больших проектах с большой командой.
Примером могут служить системы, от которых зависят жизни людей: медицина, транспорт, энергетика. Обычно подобные системы разрабатываются в соответствии с отраслевыми стандартами, многократно тестируются, подлежат лицензированию. Лёгкие методологии в подобных системах не работают. Как вы знаете, в них живое общение предпочтительнее документации, но, например, если ваше приложение будет тестироваться несколько раз разными командами, то лучше, если этот процесс тщательно задокументирован. Если в команде десятки человек, то никакой владелец продукта (представитель заказчика по терминологии скрам) не сможет им всем постоянно разъяснять требования.
Таким образом, если вам требуется формализованный подход, то вашим выбором станут такие методологии как RUP, OpenUp, EssUp. Такие методологии являются больше чем методологиями и правильнее их называть фреймворки процессов. Они изначально созданы для итеративной модели, однако, их можно путём модификаций использовать и в каскадной модели.
Если же нам формализованный подход не нужен, тогда мы будем использовать, так называемые, гибкие методологии. Скорость или качество? На самом деле здесь подразумевается немного более сложная формулировка: продуктивность или инженерия?
Под продуктивностью понимается наиболее быстрый процесс добавления функционала в приложение. Под инженерией подразумевается высокий уровень организации разработки, новаторские подходы и сложные приёмы, которые могут быть применены только опытной командой. Я говорю о таких практиках экстремального программирования как разработка через тестирование, непрерывная интеграция, парное программирование и т.п. Особенность экстремального программирования заключается в том, что обязательно нужно использовать все 12 практик, только тогда эффект от них становится максимальным. Если вы не будете использовать какую-то практику, она обязательно потянет за собой все остальные. Например, если вы откажетесь от юнит тестов, тогда вы не сможете делать частые рефакторинги, без рефакторингов вы не сможете обеспечить простую архитектуру (как мы знаем простую архитектуру разработать сложнее, чем сложную) и т.п.
Однако вы можете использовать практики экстремального программирования в других методологиях, более того, это может быть очень полезным. Например, вы можете использовать парное программирование в Скраме, чтобы помочь новичкам быстрее влиться в проект. Таким образом, экстремальное программирование может обеспечить высокое качество за счёт более высокого уровня инженерии, но при выборе этой методологии проект может получиться дороже. Также для успешного применения обязательно требуется команда, уже имеющая опыт использования данной методологии.
Если же вам нужна максимальная продуктивность, то также есть варианты. Скрам ориентирован на постоянное усовершенствование процесса. Для этого у него есть митинг ретроспективы, которые проводятся в конце спринта. Также во время обзора спринта обсуждается, что было сделано хорошо, что плохо и что улучшить. Если у вас опытная команда, хорошо отлаженный процесс и вам в принципе не нужны совершенствования, то следование методологии Скрам будет отнимать у вас слишком много времени, которое вы могли бы потратить с большей пользой. Например, по Скраму, если спринт длится 1 месяц, то обзор спринта должен занимать 4 часа и ретроспектива спринта – 3 часа. Плюс к этому есть планирование спринта, длящееся 8 часов и ежедневные Скрам митинги по 15 минут.
Если у вас, к примеру, неслаженная команда, либо используются нопробованные технологии или незнакомая сфера применения вашего приложения или всё вместе взятое, то выбор методологии Скрам может быть прекрасным решением. Когда начинается новый проект, можно начать использовать Скрам, а когда процесс станет более отлаженным, архитектура стабилизируется, потребность в постоянных улучшениях отпадёт, то можно перейти к другой методологии, например, Канбан.
Если совершенствования не нужны и всё, что нужно, это сконцентрироваться на выполнении задач, то хорошо подойдёт RAD или Kanban. RAD имеет много общего с agile методологиями, но в нём есть существенное ограничение на длительность проекта. Желательно не более 60-90 дней. Канбан похож на некий беспрерывный конвейер, который может длиться бесконечно. Он хорошо работает на проектах поддержки, но плохо там, где требуется разработать сложную архитектуру, т.к. ориентирован на быстрое добавление фич в приложение. Под фичами имеется в виду кусок функциональности, который виден пользователю и непосредственно решает какую-либо его задачу. Например, логирование, оптимизация и масштабируемость пользователю не видны, это не фичи в терминологии Канбан. А вот новая страница, отчёт, дополнительные фильтры в поиске— это то, что видно пользователю и является фичей.
Источники:
1. Dr. Winston, W. Royce. Managing development of large software systems. 1970. http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
2. W Boehm, A spiral model of software development and enhancement. 1986. http://csse.usc.edu//TECHRPTS/1988/usccse88-500/usccse88-500.pdf
3. W Boehm. Spiral Development: Experience, Principles, and Refinements. 2000. http://www.sei.cmu.edu/reports/00sr008.pdf
4. С. Белоусова, И. Бессонова, Руджеро Гиляревский. Введение в программные системы и их разработку. НИУ ВШЭ. http://www.intuit.ru/studies/courses/3632/874/info
5. К. Швабер, Д. Сазерленд.Скрам Гайд. Исчерпывающее руководство по Скраму: Правила игры.
http://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-RUS.pdf#zoom=100
6. Rational Unified Process. Best Practices for Software. Development Teams. http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf
Introduction to OpenUP. http://epf.eclipse.org/wikis/openup/
7. Х. Книберг, М. Скарин. Scrum и Kanban: Выжимаем максимум. InfoQ. 2010
8. К. Ауэр, Р. Миллер. Экстремальное программирование. Постановка процессов. – СПб.: Питер: 2004
9. Экстремальное программирование – реальность и мифы. skipy.ru/philosophy/xp.html
10. M. Stephens, D. Rosenberg. Extreme Programming Refactored: The Case Against XP. APress, USA, 2003
11. James Christie. The seductive and dangerous V Model.
http://www.clarotesting.com/page11.htm
12. Adel Alshamrani. A Comparison Between Three SDLC Models Waterfall Model, Spiral Model, and Incremental/Iterative Model. http://www.academia.edu/10793943/A_Comparison_Between_Three_SDLC_Models_Waterfall_Model_Spiral_Model_and_Incremental_Iterative_Model
Автор: artur_g
