Структура методологии разработки/внедрения программного обеспечения

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

• Что?
  Что мы делаем: разрабатываем новое ПО с нуля, занимаемся офшорным программированием, внедряем готовую систему или всего понемножку.
  
  
• Кто?
  Состав команды, выполняющей проект. Например: бизнес-аналитик, системный аналитик, архитектор, разработчики, тестировщики, технический писатель.
  
  
• Как?
  Основные этапы и принципы организации процесса. Например, процесс итерационный, каждая итерация длится 2-4 недели и заканчивается поставкой новой версии заказчику. Итерация состоит из этапов анализа, проектирования, разработки, тестирования, внедрения.
  
  Стоит заметить, что некоторые методологии, например Oracle Unified Method, идут дальше и предлагают подробный состав работ. При этом в описании каждой работы приведен еще и шаблон документа, которым должно заканчиваться исполнение данной работы.
  
  
• Обряды
  В каком-то смысле это часть ответа на вопрос "Как?". Обряд - это важное для успеха проекта по мнению участников действие. Например, ежедневные пионерские линейки.
  
  
• Внутренние артефакты
  Внутренние артефакты - средства коммуникации внутри команды. Это может быть доска с диаграммой сгорания задач, техническое задание, спецификация информационных потоков и т.д.
  
  
• Внешние артефакты
  По-сути, это - то, чем команда будет отчитываться перед заказчиком. В российских реалиях это обычно следующие документы: технические требования, техническое задание, эскизный проект, технический проект, рабочий проект, программа и методика испытаний, протокол испытаний.
  

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

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

Если вы не согласны и у вас свои взгляды на процесс разработки, то добро пожаловать в комментарии.

P.S. Для затравки:

• Экстремальное программирование - реальность и мифы.
  
• Обзор методологии Scrum.
  
• Методология Oracle Unified Method.

Понравилось сообщение - подпишитесь на блог и Twitter