Производство против разработки программного обеспечения [закрыто]

Часто говорят, что индустрия программного обеспечения незрелая по сравнению с производством. В частности, что касается процесса.

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

Мое мнение : при производстве создание продукта сильно зависит от процесса. У вас может быть фабрика, где у каждого человека есть определенный набор задач, которым они следуют. Рабочий (или робот) может затягивать винт весь день. Затем следующая задача в процессе выполняется следующим специалистом. Рабочие (и роботы) не удерживаются от процесса и не делают что-то «на лету». Детали проходят через весь процесс, и на выходе получается готовая продукция. Это работает хорошо, и компании достигают 99,9996% бездефектных продуктов. Компании с течением времени сглаживают неэффективность. Это впечатляет и вполне может быть признаком зрелой индустрии.

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

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

Для создания сложных алгоритмов, которые еще предстоит понять человеческому разуму, необходимо создавать вещи на лету. Разработка программного обеспечения - это не следование процессу, а создание процессов, выполняемых компьютером. Это принципиальная разница. Независимо от того, сколько ортогональных процессов мы развиваем вокруг разработки, мы всегда будем прибегать к этому «на лету», когда речь идет о творчестве.

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

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

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

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

Если мы посмотрим на процессы проектирования продуктов, то лучшие отрасли, на которые стоит обратить внимание, делятся на две категории:

• те, где производство может быть реализовано по товарным ставкам; например, звукозаписывающая индустрия (1% или менее от стоимости компакт-диска - выпечка и печать), графические носители и т. д.
• те, где количество настолько мало, что фаза проектирования является наиболее заметным фактором стоимости (предметы роскоши, продукты с индивидуальным заказом, нишевые рынки ...)

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

Если вы хотите писать одно и то же программное обеспечение снова и снова (в отличие от простого копирования), вы можете сделать это очень эффективно через сборочную линию.

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

Я думаю, что ответ, который вы ищете, здесь применим или реалистичен. Я чувствую, что вы хотите знать, как мы можем настроить наши процессы так, чтобы они больше походили на обрабатывающую промышленность. Вместо этого я думаю, что реальный вопрос становится следующим: «Зная, что производственные и другие отрасли делают для создания качественной продукции, чему мы можем научиться?» или "Что может сделать индустрия программного обеспечения для улучшения качества?"

К сожалению, ответ на этот вопрос неясен, потому что сама индустрия программного обеспечения до сих пор не знает ответа. Чтобы ответить на этот вопрос, индустрия программного обеспечения должна провести исследование того, что работает и почему? Например, были исследования, которые показывают, что Test Drive Design (TDD) приводит к улучшению качества. Хотя вопрос производительности все еще остается без ответа или, по крайней мере, еще не полностью понят. Насколько доказательство показывает, что:

• Обзоры кода превосходны, и было показано, что они находят большинство ошибок, но эффективность рецензирования довольно резко падает после первого часа рецензирования. Учитывая, что средний человек может читать только несколько сотен строк кода в час, он предлагает разработчикам разбить изменения на более мелкие части.
• Чем дольше будет найдена ошибка, тем дороже (время и деньги) будет ее исправить. Таким образом, если разработчик находит его во время написания кода, мы говорим, что стоимость равна 1. Если юнит-тест обнаружит его позже, то стоимость будет равна 10, если EVT обнаружит, что стоимость равна 100 и так далее.
• Существуют некоторые свидетельства того, что чем сложнее требования, тем сложнее решение и чем сложнее решение, тем больше вероятность появления ошибок.

Есть человек по имени Грег Уилсон, который несколько лет назад отлично рассказал об этом. Вот ссылка на доклад: Грег Уилсон Talk

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

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

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

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

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

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

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

Ответ: да, конечно. Есть много уроков, которые разработчики программного обеспечения могут извлечь из производства, несмотря на тот факт, что разработка программного обеспечения является творческим процессом. Разработка программного обеспечения сама по себе является процессом и включает в себя множество других процессов. Чем лучше вы сможете определять и контролировать эти процессы, тем лучше вы сможете контролировать процесс разработки программного обеспечения в целом. Это не значит, что вы должны прописывать каждое нажатие клавиши, которое делает разработчик; это просто означает, что как разработчик вы естественным образом выполняете задачи в определенном порядке, и этими задачами часто можно управлять. Вот некоторые примеры:

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

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

• дизайн продукта: Вы решаете, какие функции реализовать, бросая дротики в стену, покрытую пост-итоговыми заметками? Если так, у вас есть процесс. Я не думаю, что кто-то будет утверждать, что это отличный процесс, но, по крайней мере, это отправная точка. Если вы измените процесс, как вы можете точно знать, что ваши изменения действительно были улучшением, если вы не проводите измерения до и после? Ты не можешь

• проверки кода: будет ли проверка кода полезной, если процесс проверки и критерии кодирования меняются для каждой проверки? Конечно, нет.

• Жизненный цикл разработки программного обеспечения: весь анализ -> проектирование -> внедрение -> тестирование -> цикл обслуживания - это процесс, который должен быть четко определен.

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

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

Разработка программного обеспечения уже приняла много производственных концепций:

• Трудно не увидеть влияние взаимозаменяемых частей Эли Уитни как на ООП, так и на разработку компонентов .

• Методы управления проектами, используемые при разработке программного обеспечения, не сильно отличаются от разработанных для производства. В качестве всего лишь двух примеров мир программного обеспечения только недавно принял концепцию Kanban, которая была разработана десятилетиями назад в Toyota, и диаграммы Ганта использовались в производстве задолго до создания первого электронного компьютера.

• Методологии управления качеством, такие как Six Sigma, которые были разработаны для производства, были адаптированы для разработки программного обеспечения.

Несмотря на сложную среду, управляемую процессами, разработчик должен заниматься созданием вещей «на лету».

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

Делать вещи на лету противоречит духу производства.

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