Обзор процесса разработки программного обеспечения

Введение


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

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

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

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

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

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

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

Нашими заказчиками являются органы власти, крупные государственные и коммерческие организации и, конечно, мы сами. Поэтому в смысле заказного ПО в нашем процессе часто присутствует некоторая разница между процессами разработки продуктов для внутреннего и для внешнего заказчиков. Некоторые нюансы я укажу в этой статье. Уровень формализации отношений с заказчиком у нас варьируется от проекта к проекту очень широко. В целом, чем больше бюджет проекта, тем выше формальность. Государственный заказчик или крупные коммерческие предприятия (особенно с государственным участием) обычно имеют законодательные ограничения на формирование, размещение заказа и приёмку результатов работ. Ещё одним ограничением крупных организаций является тот факт, что их персонал, являющийся источником требований и основным пользователем наших систем, имеет очень ограниченную доступность для исполнителей, хотя бы вследствие своей занятости. Однако для небольших организаций уровень формализации падает и иногда уходит в противоположную крайность, где возникает недостаточный уровень ответственности заказчика в рамках проекта.

Другая сторона наших заказных проектов – высокие требования к функциональности. Это и высокая нагрузка на все системы, и большая географическая распределённость, и высокие требования к точности вычислений при очень ограниченных временных рамках. Часто в наших проектах появляются элементы исследовательской работы и творческого поиска, направленного на решение нетривиальных проектных задач. Иногда нам приходится комбинировать в рамках одного процесса разработки разные методологии, например, вставляя в общий процесс, близкий к RUP, один или несколько этапов почти чистого scrum, порождая что-то вроде проекта в проекте. Это позволяет нам сохранять невысокий уровень вовлеченности пользователей, связанный с природой проекта, с гибкостью разработки в условиях высокой неопределённости требований. В этом плане для меня важен именно подготовительный этап, во время которого можно выбрать необходимую методологию и выстроить оптимальный процесс разработки. Один из примеров применения гибкой методологии я описал в статье «Применение agile при разработке проекта для государственного заказчика».

В качестве примера работы над инвестиционным проектом я могу привести разработку комплексной системы безопасности, которую мы создавали как «коробочный» продукт. Под моим руководством было выпущено последовательно четыре версии этой системы, пользователями которой стали самые разные коммерческие и государственные организации, включая мэрию Москвы, АФК «Система», банки, бизнес-центры и, конечно, наш собственный офис. Первая версия была не очень успешной, но у нас была стратегия развития, которая позволила нам успешно захватить рынок и пережить сложные времена кризиса. Опыт работы над этим и ещё несколькими инвестиционными проектами тоже был учтён при формировании используемого мной процесса разработки.

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

Важно понимать, что переход процесса от одного этапа к другому не имеет чёткой границы. Как правило, работы следующего этапа начинаются по мере выполнения 80-90% работ по предыдущему этапу. Особенно это касается разработки требований, когда в ряде случаев снятие неопределённости происходит лишь к концу проекта. Безусловно, наличие такой неопределённости в проекте является существенным риском и должно находиться под постоянным контролем.

Процесс разработки заказного ПО


Обзор процесса разработки начнём с наиболее общего случая – разработки заказного программного обеспечения. Схема процесса приведена на рисунке 1.

image
Рисунок 1. Процесс разработки заказного программного обеспечения.

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

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

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

Иногда уточнение требований приводит к пересмотру концепции проекта. Если после уточнения всех требований не удаётся найти приемлемого технического решения, проект приходится сворачивать либо откладывать на некоторое время в ожидании более приемлемых обстоятельств.

Если техническое решение найдено, исполнитель приступает к разработке архитектуры будущей системы. Цель этапа – определение верхнеуровневой логической и физической архитектуры, полностью покрывающей все требования заказчика. При разработке архитектуры проводится рецензирование и уточнение концепции, требований и предварительного технического решения, что даёт возможность предупредить наиболее опасные риски.

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

Если баланс был найден, и удалось создать приемлемую архитектуру системы, исполнитель может переходить к реализации и поставке системы. Реализация может проходить в один или несколько этапов. Для небольших проектов одноэтапная поставка всего функционала системы может быть вполне приемлемой. Однако, чем больше проект, тем выше зависимости подсистем внутри создаваемой системы. В этих условиях следует делить реализацию на несколько этапов так, чтобы в конце каждого этапа команда разработчиков имела готовый к поставке продукт. При этом самый важный, фундаментальный функционал должен разрабатываться на ранних этапах, а надстройки, работающие поверх этих основных компонентов, следует реализовывать позднее. В таком случае наиболее опасные для системы ошибки будут исправлены на первых этапах, и риск того, что прикладная функциональность системы будет основана на нестабильной основе, будет значительно снижен.
После поставки полностью завершённой системы проект заказного ПО обычно переходит к этапу опытной эксплуатации. Цель этого этапа заключается в проверке качества работы разработанной системы в реальных условиях эксплуатации. Как правило, на этом этапе исполнитель совместно с заказчиком проводит измерение количественных метрик, позволяющих определить качество созданной системы. В первую очередь проверяются функциональные характеристики качества, затем – нефункциональные. При наличии несоответствий исполнитель корректирует код системы.

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

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

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

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

Процесс разработки инвестиционного ПО


Процесс разработки инвестиционного ПО отличается тем, что параллельно может идти работа сразу над несколькими версиями продукта: пока первая версия сопровождается, вторая уже реализуется, а для третьей формулируются требования. Процесс показан на рисунке 2.

image
Рисунок 2. Процесс разработки инвестиционного программного обеспечения.

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

Обратите внимание на момент начала работ над следующей версией продукта. Этот момент настаёт, как только пройден этап создания архитектуры текущей разрабатываемой версии. До этого на этапах формирования требований и создания архитектуры, как правило, идёт обсуждение, какие функции следует реализовать в текущей версии, а какие перенести на будущее. И только тогда, когда требования к текущей версии сформулированы, рецензированы и подтверждены архитектурой системы, имеет смысл думать о следующей версии.

Кроме того, после разработки архитектуры, как правило, у аналитиков и архитекторов проекта появляется некоторая свобода действий, поскольку на этапах поставки основная нагрузка ложится на программистов. Эту свободу можно использовать для проработки концепции и требований для следующей версии.

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

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

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

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

Особое внимание нужно уделить стендам, на которых проводится тестирование: на них должны быть развёрнуты все версии продукта, которые были выпущены ранее (по меньшей мере, те версии, которые сопровождаются), и все версии, разработка которых ведётся в настоящий момент.

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

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

Процесс разработки встроенного ПО


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

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

Таким образом, при разработке встроенного ПО возникает сразу несколько важных ограничений.

Во-первых, поставка выполняется в рамках только одного этапа: никто не будет встраивать в устройства наполовину работающую программу.

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

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

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

Процесс разработки встроенного ПО показан на рисунке 3.

image
Рисунок 3. Процесс разработки встроенного программного обеспечения.

Процесс разработки игр


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

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

Указанные факторы сказываются на процессе разработки игрового ПО. Процесс представлен на рисунке 4.

image
Рисунок 4. Процесс разработки игрового программного обеспечения.

Нужно отметить следующие особенности процесса разработки игрового ПО.

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

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

Поставка игрового программного обеспечения происходит в рамках одного единственного этапа. Даже если сначала создаётся некое ядро, «движок» игровой системы, его работу невозможно проверить без реализации всего функционала системы.

Для игрового ПО нет этапов опытной эксплуатации и вывода из эксплуатации. Игры сразу поступают в продажу, а после использования просто удаляются пользователем по мере утраты интереса к ним.

Заключение


В рамках статьи я попытался сделать обзор «верхнего уровня» процесса разработки прикладного программного обеспечения. Каждый этап процесса, безусловно, нуждается в отдельном обсуждении с обязательным учётом особенностей разрабатываемых программных средств.

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

Продолжение: Подготовительный этап разработки программного обеспечения
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 45
  • –8
    «Разработка требований» режет слух, не лучше ли говорить «сборка требований»?
    • +2
      Нет не лучше.
      В данном случае имеется в виду «разработка документа(ов) с требованиями к ПО»
      • +3
        Я сознательно употребляю термин «разработка требований», поскольку аналитикам и архитекторам часто приходится приложить немалые усилия для того, чтобы выяснить реальные потребности заказчика и сопоставить их с потребностями бизнеса своей организации.

        Если этого не сделать, то можно попасть в две крайности: либо в список требований будет содержать много никому не нужных функций, которые придётся реализовать, отладить и сопровождать, либо список окажется не полным, и в итоге ПО окажется никому не нужной, а репутация исполнителя — сильно подмоченной. То и другое выливается в значительно (на порядок) бОльшие затраты, чем затраты на качественную разработку требований в начале проекта.

        В большинстве проектов, где аналитики просто занимаются «сбором требований», исполнитель умудряется попасть в обе эти крайности одновременно.
        • 0
          Afaik устоявшийся термин «Анализ требований»
      • 0
        А где же Agile проектирование, Экстрема́льное программи́рование и ему подобные? По сути надо было написать «Обзор водопадной модели процесса разработки программного обеспечения». Вообще-то водопадная (каскадная) модель по-моим наблюдениям уже даже не самая популярная и многими считается устаревшей.
        • 0
          Многими заказчиками или программистами и архитекторами?
          • +2
            И теми и другими, если говорить о зарубежных компаниях. Ради интереса поищите вакансии java разработчик в Европе/США, в доброй половине вы увидите требования знания Agile или XP программирования, что как бы намекает на что сейчас мода.
            • 0
              В Европе/США вполне возможно, но вот у нас я слабо могу себе представить тендер на разработку ПО по методологии Agile…
              С играми похожая история, я бы не стал покупать диск с первой итерацией новой игры на консоль…
              • 0
                тендер на разработку ПО по методологии Agile

                А что есть тендер на разработку ПО по каскадной методологии? Методология это процесс взаимодействия с заказчиком и выдачи релизов, а не тендеров. На самом деле, процесс непрерывных уточнений у заказов и показов некоторых прототипов достаточно часто встречается (при том что ни исполнитель ни заказчик не подозревают что работают по Agile модели).

                С играми похожая история, я бы не стал покупать диск с первой итерацией новой игры на консоль…

                Заказчик в методологии Agile не обязательно покупатель, это может быть преальфа тестер, задачей которого определить «играбельность» каждой итерации.

                P.S. На самом деле, методология проектирования не имеет отношения ни к тендерам, ни к продажам.
                • 0
                  > А что есть тендер на разработку ПО по каскадной методологии? Методология это процесс взаимодействия с заказчиком и выдачи релизов, а не тендеров. На самом деле, процесс непрерывных уточнений у заказов и показов некоторых прототипов достаточно часто встречается (при том что ни исполнитель ни заказчик не подозревают что работают по Agile модели).

                  Из того, что я обычно видел — ещё на этапе заключения договора обговаривается конкретный график разработки продукта, ряд промежуточных этапов приёмки, на которых уже должны быть реализованы конкретные требования. Это водопад, никак не Agile.

                  Реальность, конечно, вносит свои коррективы порой. И какая то часть Agile тут может присутствовать.
                  • 0
                    Это водопад, никак не Agile.

                    Может просто потому, что заказчик вообще не сильно в курсе существования Agile, а исполнитель не объясняет этому заказчику все плюсы итеративного подхода и риски водопадного?
                    • 0
                      Я тут могу ошибаться, но многие вещи прописаны в законах и стандартах выполнения проектов и тд. Не так просто может быть их поменять.
                      • 0
                        А можно пример? Сомневаюсь, что кому-то кроме гос. компаний есть дело до гос. стандартов и т.п… Да и если гос. организация начала диктовать условия работы — это отличный повод задуматься над тем, чтобы отказаться от проекта, пока не поздно.
                        • 0
                          Если вы делаете проект для государственного учреждения, то вы должны работать по их требованиям. Отказаться от проекта можно, конечно, кто же спорит. Кому то всё равно его придётся делать.
                      • 0
                        Нет, как правило дело не в этом. Просто в большей своей массе российские компании имеют понятие «бюджета» и его выделения, а соответственно и «fixed price», что в итоге приводит к обязательному наличию «ТЗ». Все эти " волшебные слова" фактически исключают возможность работы по agile-методологиям. И даже если команда «внутри» работает гибко, то для заказчика это все равно каскад. Крайне мало заказчиков с которыми нам приходилось работать готовы использовать agile и time&materials. Причём чем крупнее заказчик, тем меньше на это шансов.
                      • 0
                        Интересная история от Фаулера на эту тему www.martinfowler.com/bliki/ScopeLimbering.html
                    • +1
                      С играми похожая история, я бы не стал покупать диск с первой итерацией новой игры на консоль…


                      1. Бывают ли игры кроме тех, которые распространяются на дисках под консоль? Я вот, например, слышал что бывают мобильные и браузеры игры.
                      2. Поищите описание какого-нибудь agile процесса разработки например наберите «scrum guide» в поисковике. Поищите там слово release — как правило релизится результат не каждой итерации или методология допускает такое.
                      • 0
                        Тренеры Олег и Сергей Дмитриевы рассказывали про свой успешный опыт участия в гос тендерах на agile разработку в ЕС, но там условия тендера отличались от наших гос проектов.

                        Гибкая методология — вполне применимая модель разработки ПО. Если заказчику нужна автоматизация критичных бизнес-процессов, но не по «высеченому в камне» тех заданию, а когда в процессе разработки и эксплуатации меняются требования к системе, область новая, много рисков и не учтенных факторов. Когда компания сама получает доход от такой автоматизации, а не делает ее для «галочки».

                        Agile методология — просто инструмент, который имеет свои условия применения и область в которой он успешно решает задачи.
                        Вряд ли удобно будет забивать гвозди отверткой или микроскопом. И использование только техник из agile не гарантирует что процесс разработки сразу становится гибким.

                        Поддерживает более простую модель, учитывающую изменение требований к системе, более жизненную приоритезацию задач, возможность быстро получить minimum viable product (MVP). Но в этом случае нельзя жестко фиксировать сразу бюджет, объем работ, время разработки и качество, все равно в сложном проекте это не угадаешь.
                        • 0
                          Не угадаешь, но всем хочется максимального контроля за бюджетом (по факту точную цифру ещё до начала работ). Поэтому и получается, что выбирая между гибкостью (agile, time&materials etc) и контролем бюджета (waterfall, fixed price), наши компании выбирают второе. В такой схеме все риски «не угадывания» виснут на исполнителе и без монолитного ТЗ можно просто пролететь. Так и живём.
                    • 0
                      Многими всеми. Только они внимание акцентирует на разном.
                    • +1
                      Согласен. Но я не случайно написал в статье, что схема процесса является результатом обобщения моего личного опыта. Так сложилось, что для заказчиков, с которыми я работаю, и для моего руководства указанная схема оказалась наиболее удобной. Я не говорю о том, что мой обзор полный. Напротив, цель статьи — указать на особенности процесса разработки, с которыми мне приходилось сталкиваться.

                      Буду признателен, если Вы укажете на какие-либо нюансы, которые могли бы улучшить приведённую мной схему, или расскажете о схеме, которую используете Вы.
                      • +2
                        для моего руководства указанная схема оказалась наиболее удобной


                        Какие альтернативы рассматривались и почему не подошли?
                        • 0
                          Пример заказного ПО. Системное ПО для обеспечения процесса прогнозирования Единой энергосистемы России. Рассчитывается прогноз по всем типам оборудования, участвующим в генерации, передаче и потреблении электроэнергии, с учётом международных перетоков. Система чрезвычайно высоконагруженная, требует высокой точности вычислений, высочайшей надёжности: от её работы зависит, насколько точно будет сбалансировано производство электроэнергии и её потребление. Чтобы создать систему, пришлось изучать специфику каждого типа оборудования, специфику управления ими, фактически, специфику работы специалистов, управляющим энергосистемой. Архитекторам и программистам пришлось бороться за каждый байт и за каждый такт процессора. Нужно было учитывать специфику виртуализации вычислительных ресурсов. И ещё многое другое. Заказчик при этом не может надолго предоставить нам своих диспетчеров: они, поверьте, очень занятые люди. Всю систему нужно поставлять только целиком: никому не нужно ПО, рассчитывающее только 99% модели. Моя схема сработала: мы выпустили ПО в срок (хотя опытная эксплуатация несколько затянулась: был ряд моментов. которые можно было отследить только в боевых условиях).

                          Пример инвестиционного ПО. Мы долгое время разрабатывали одну комплексную систему безопасности. Под моим руководством было выпущено последовательно четыре версии этой системы. Она использовалась в мэрии Москвы, АФК «Система», ВГТРК и ещё тысячах организациях, начиная с нашего собственного офиса. Первая версия была не очень успешной, но у нас была стратегия развития, которая позволила нам успешно захватить рынок. В тот момент, когда Россию накрыл кризис 2008-2009 года, мы не только не потеряли доходы, но и получили новый сегмент: бизнес-центры решили вкладывать в нашу систему на пике кризиса, хотя раньше не были на это готовы. Моя схема сработала.

                          Мы годами оттачиваем свои процессы. У нас много проектов, и мы гордимся, что наши продукты работают, а наши заказчики рекомендуют нас своим партнёрам.

                          Я не против гибкой методологии. Но я хочу говорить о том, что работает на практике для действительно сложных систем. Мой опыт двадцатилетней работы показывает, что приведённая в статье схема точно работает. И она для наших проектов достаточно гибкая.
                          • 0
                            Спасибо. Мне кажется, надо такое вставлять в статью.

                            «Всю систему нужно поставлять только целиком: никому не нужно ПО, рассчитывающее только 99% модели.»

                            А нельзя как-то по другому композировать. Например «ПО рассчитывающее 100% модели, но только для конкретного подразделения» или «По, расчитывающее 90% модели, а 10% расчитывается так же как и сейчас».

                            Я не против гибкой методологии.


                            А какие не-agile методологии вы рассматривали?
                            • 0
                              Спасибо. Мне кажется, надо такое вставлять в статью.

                              Да, учту это на будущее :)

                              А нельзя как-то по другому композировать.

                              Композировать получилось. Но не разбитием модели: она теряет смысл при малейшей потере целостности.

                              Мы применили известный подход многоэтапной поставки. Плюс некоторые наши практические наработки.

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

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

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

                              Я бы сказал, что в данном проекте схема процесса в целом была наиболее близка к RUP с жёстким контролем концепции проекта, но со своей спецификой.
                      • 0
                        А чем Agile не вписывается в показанные модели? Там же есть итеративность. Agile-же вообще скорее про ценности, а не про то, что нет структурированного подхода :)
                      • +1
                        Поправьте меня, если ошибаюсь, но разве цикл разработки в общем виде для данной модели не «Сбор требований -> Анализ -> Проектирование -> Разработка -> Тестирование -> Внедрение»?
                        • 0
                          Не вижу списка источников и списка проанализированных разновидностей процессов. Если автор наблюдал эти процессы своими глазами, то хотелось бы примеров и ссылок компании. Если автор рассматривал процессы как они описаны в литературе, то хотелось бы ссылок на литературу.
                          • 0
                            Статья — обобщение моего опыта в надежде, что это поможет кому-то из моих коллег. Поэтому списка литературы не даю.

                            Примеры указал в ответе на один из комментариев выше. Но детально их раскладывать в статье, посвящённой только «верхнеуровневому» обзору используемого мной процесса, считаю, неуместным. Чтобы такой пример в статье был полезен, мне бы пришлось углубляться в каждый этап процесса, и тогда вместо статьи получилась бы увесистая книга.
                            • 0
                              Спасибо за примеры. Просто с точки зрения читателя, перво-наперво интересно почему я должен доверять данной информации. Это может быть либо авторитет автора либо ссылки на источники.

                              Я думаю, уместно вкратце рассказать об опыте и сделанных проектах (например, так как вы сделали в коментарии) и про то, какие варианты процессов разработки были рассмотрены и почему не подошли.
                              • 0
                                Спасибо, это ценное замечание. Обязательно учту в будущем.
                          • +3
                            существует несколько видов программного обеспечения
                            белое, пушистое, теплое и жаренное. Иногда белое бывает пушистым, теплое — жаренным. Тем не менее
                            остановлюсь только на различиях именно самого процесса касаемо разных видов ПО.
                            Пушистое отличается от белого наличием форков.
                            Теплое не отличается от пушистого, но имеет ограничения.
                            Жаренное отличается от теплого особенностями.

                            Куда вы отнесете заказную разработку прошивки для игровой приставки, с разными аппаратными версиями? или это будет пятый тип «шуршащее»?
                            • +4
                              Дочитал абзацы про виды ПО и дальше читать не стал. Автор не владеет предметной областью.

                              Жирный минус.
                              • 0
                                Коллеги, я стал программистом не потому, что мне нравятся черно-серые квадраты, соединенные линиями. Несколько мрачное ощущение. Ничего нового для себя не увидел. Вы не перепутали выражения «разработка по» и «управление проектом»? Как программисту мне эта статья никак не помогает. Если вы действительно хотели затронуть тему разработки, то обсудили бы какую-нибудь комбинацию репозиториев и систем сборки, например, habrahabr.ru/post/75990. Там со знанием дела человек рассказывает, как он управляет проектами на уровне исходников. Причем мне кажется, актуальность эта статья не потеряла. С тех времен прошло уже 6 лет, появились bower, grunt, например, для упрощения разработки под web, хорошо подрос maven для джавистов, nuget для visual studio и прочее или полезное или специфическое. А вы рассказываете так, как я слышал это 20 лет назад в университете. Кстати, некоторые процессы отображаются другими геометрическими фигурами. )))
                                Срочно исправляйтесь!!!
                                • 0
                                  И не подумаю ;)

                                  Серые квадраты нарисованы для тех, кто отвечает за организацию процесса разработки программного обеспечения. Программистам обычно эти схемы не показывают, потому как активность программистов — несколько точек в одном из этих серых квадратов.
                                  • 0
                                    Программистам обычно эти схемы не показывают
                                    Позвольте, а что тут секретного или непонятного? У разработчиков в голове схемы и посложнее бывают.

                                    Вот ещё момент из вашей статьи:
                                    Кроме того, пользователи игровых программ, даже столкнувшись с ошибкой в игре, очень редко загружают обновлённую версию

                                    Лично я не большой любитель игр, но вот на ipad тащусь от одной глупой casual игры (hill climb). Они периодически выпускают обновления, добавляя новый уровень или какой-либо элемент игры, а заодно исправляя ошибки. Я даже жду их обновления. Так что я не глупый пользователь, который не загружает обновлений.

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


                                    Можно узнать, о чём идёт речь? Что за проекты из которых вы вынесли такие схемы, ваше участие в проектах?
                                  • 0
                                    Вы не перепутали выражения «разработка по» и «управление проектом»?

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

                                    А вы рассказываете так, как я слышал это 20 лет назад в университете.

                                    Потому что оно не поменялось. Много чего добавили и расширили, но основа та же. Хотя появились и другие модели. Но то что вы описали про сборку/репозитории — это совсем из другой оперы.
                                    • 0
                                      Здесь «технология разработки ПО», а не «технологии в программировании».
                                      Выработка тербований, проектирование, документирование, поддержка, само написание кода — все входит в «процесс разработки ПО»

                                      И что из перечисленного вами не должен делать программист или другой участник команды, который имеет отношение к коду? По мне так даже программист должен словами написать в коммите, что он закодировал, а ещё лучше писать документацию, что сделано. Это можно делать в конце дня и это не занимает больше 10-15 минут времени в день. А другим проще будет понять, что делает сосед. Всё-таки программы пишутся для людей и именно другие люди должны понимать, что сделано.

                                      Но то что вы описали про сборку/репозитории — это совсем из другой оперы
                                      Все слова и договорённости должны каким-то образом учитываться в коде и попадать в сборку. Или нет?
                                      • 0
                                        Это обычная путаница (и холивор) между «программист» и «разработчик ПО».

                                        Всё-таки программы пишутся для людей и именно другие люди должны понимать, что сделано.


                                        В микроскопической команде все возможно. В крупных проектах создание ТЗ, проектирование, написание кода, тестирование и документация выполняются разными отделами, не то что людьми.
                                        То, о чем вы говорите — про коммиты, «систему сборки» и пр — это уровень только «написание кода». То, что осуждается в статье — все стадии, и помянутые системы сборки — только малая часть.
                                  • +2
                                    А на каком этапе нужно собственно код писать?
                                    • –2
                                      Реализация происходит на этапах поставки.

                                      Умышленно не говорю о написании кода. Реализация и поставка системы — тема очень большая, кроме кодирования в неё входит много других активностей. На эту тему надо говорить отдельно.
                                    • +2
                                      Это было в Симпсонах^W^W у Джоэля: www.joelonsoftware.com/articles/FiveWorlds.html
                                      • –2
                                        Хорошая параллель. Я согласен с Джоэлем Спольски в некоторых его выводах. В частности, в том, что в процессе разработки нужно учитывать особенности разрабатываемого ПО. И я этим активно пользуюсь.
                                      • 0
                                        Занимаюсь разработкой 16 лет. За это время удалось поработать в разных отраслях, в разных компаниях, на разных должностях.

                                        Впечатление от статьи скептическое. Даже если это было попыткой осветить процессы совсем теоретически — по факту ни одного «гола».
                                        • 0
                                          Для того, чтобы учесть замечания, высказанные здесь коллегами, и лучше связать материал с новой статьёй «Подготовительный этап разработки программного обеспечения», я несколько изменил текст.

                                          Спасибо всем за конструктивные замечания!

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.