Когда интерфейс имеет значение

Блог

Галопом по методологиям

Галопом по методологиям

07.03.2012

 

Станислав Елисеев, директор «РосБизнесДизайн»

В методологиях не разберешься, не куя! (народная мудрость)

Когда я учился в ВУЗе, у нас был курс «Теория разработки программного обеспечения». Как сейчас помню, нам рассказывали о каких-то доисторических ГОСТах, «учили» писать технические задания и едва-едва касались вопроса, а как же управлять разработкой того самого программного обеспечения. Даже будучи студентами 4-го курса, мы прекрасно понимали: все, что нам давали, никакой пользы не приносило. Поэтому каждый делал на свой лад и заполнял этот вакуум, как мог: кто-то читал UML, получивший серьезную популярность в то время, кто-то читал книги от различных гуру Майкрософта, кто-то ориентировался на используемые CASE-программы. Система плодила самоучек. У нас не было пласта знаний, в котором мы могли бы ориентироваться, у нас не было ответов.

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

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

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

На что мы обратили внимание? 

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

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

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

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

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

Каскадная модель 

Несмотря на свою архаичность, эта модель хорошо подходит для разработки большинства сайтов и для построения космических кораблей. Казалось бы, что объединяет эти совершенно разные типы работ? Ответ — большая степень формализации, которая помогает минимизировать риски.

В соответствии с каскадной моделью, разработчики последовательно выполняют ряд шагов:

  1. Аналитика. Выявление требований
  2. Проектирование
  3. Реализация
  4. Интеграция
  5. Тестирование и багфикс
  6. Внедрение
  7. Поддержка

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

Мы активно используем следующие плюсы этой методологии:

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

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

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

Из практики

Для сайтов мы документируем требования в 4-х основных разделах и не меняем в ходе всего проекта:

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

После внедрения этой методологии у нас появилась специальность «интегратор». Это человек, который собирает результаты работ различных команд (дизайнеров, верстальщиков, программистов) в единое целое.

SCRUM

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

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

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

SCRUM проповедует ценности agile-манифеста.

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

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

Из практики

  • Методология достаточно просто внедряется (по сравнению, например, с UP), видимо, поэтому и получила широкое распространение.
  • Отлично подходит, когда ваш заказчик фонтанирует идеями, а попытки «отсечь лишнее» или хоть как-то ограничить поток желаний не имеют должного эффекта. Если такой заказчик готов к гибкому бюджету, то SCRUM — то, что доктор прописал.
  • Использование SCRUM характерно для стартапов. Особенно для customer development модели, когда продукт развивается в состоянии неопределенности, проходит несколько стадий и множество валидаций со стороны рынка.
  • Неопределенность бюджета — справедливая плата за то, чтобы не витать в собственных фантазиях, придумывая фичи, а иметь возможность «пощупать ручками».

Казалось бы, с точки зрения заказчика SCRUM — менее рискованная модель. То есть риск «увидеть результат и ужаснуться» сводится к минимуму. Заказчик видит результат каждую неделю. Но нежелание заказчика вникать в процесс и недоверие к разработчику приводит к тому, что SCRUM становится методологией для искушенных.

Unified Process

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

Unified Process — это простой собрат сложного и более известного RUP.

UP — итеративная методология с очень широким диапазоном возможных решений в части формализации процесса разработки.

Быстро понять суть UP можно из этой схемы:

По горизонтали отмечены рабочие потоки, по вертикали фазы: начало, уточнение, конструирование, внедрение. I1, E1, E2, C1 … — итерации. Количество итераций не оговорено и может различаться от проекта к проекту. По завершению каждой итерации выпускается функциональный релиз.

Главное, что нам дали итерации:

  • Мы с заказчиком больше не витаем в облаках на бесконечных встречах и не тратим время на бесполезную детализацию планов на дальную перспективу.
  • Мы спокойно занимаемся исследованиями предметной области и поиском наилучших архитектурных решений не ДО начала разработки, а ВО ВРЕМЯ.
  • Мы эффективно можем работать с потоком требований.
  • Благодаря наличию функционального релиза с первых итераций заказчик уже на ранних этапах может оценить потенциал системы.

Из практики

  • Принципы UP позволяют применять методологию в любых проектах — как с низкой степенью формализации, так и с высокой. Мы никогда не используем все возможности формализации, иначе UP превратится в крайне формальную, тяжеловесную махину. Мы пользуемся тем, что UP разрешает разрабатывать только те артефакты и выполнять только те работы и задачи, которые необходимы в конкретном проекте.
  • В принципе, при желании UP можно использовать и в «каскадных» проектах, включающих одну-две итераций.
  • Необходимость демонстрировать работающий релиз в конце итерации вынуждает разработчиков показывать настоящие результаты вместо типовых фраз «готово на 90%».

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


P.S. 17 марта состоится семинар по методологиям разработки программного обеспечения. Подробности о семинаре в социальных сетях: VK (vkontakte) и facebook.


 
назад 17 марта состоится семинар «Методологии разработки ПО» Сергей Белоусов в гостях у РБД вперед
blog comments powered by Disqus