Разработчики могут многому научиться у других отраслей. Как мыслящее упражнение, можно ли построить пассажирский самолет, используя гибкие методы?
Забыть стоимость сейчас; насколько возможно использовать итеративное и инкрементное развитие как для аппаратного обеспечения (фюзеляжа, крыла и т.д.), так и для программного обеспечения, и по-прежнему выпускать рабочий и безопасный продукт, который отвечает требованиям клиентов во время доставки?
Имеет ли смысл реорганизовать самолет?
Я собираюсь сказать "вид". На самом деле есть один пример прямо сейчас, который, я думаю, довольно близок к тому, чтобы ответить на этот вопрос.
Boeing пытается сделать это сейчас с новым 787 - см. ниже: Boeing 787 - Спецификация и сотрудничество (From 777 - 787, исходный спецификационный документ, предположительно, переместился с 2500 страниц на 20 страниц с изменением техники.) Поставщики со всего мира работают самостоятельно для разработки компонентов этого самолета. (Мы будем называть это "командами".)
Итак, я хочу сказать "да", но в то же время итерации при создании самолета привели к задержкам в 2+ года и привели к рассказам вроде этого - (787 Отложено на 5-й раз)
Будет ли когда-нибудь построен самолет? Да, конечно. Но когда вы смотрите на резину, попадающую на дорогу здесь, похоже, что "интеграционный тест" имеет один момент времени.
Edit: В то же время этот сдвиг в технике привел к созданию новой породы самолетов, построенной из совершенно новых материалов, которые, возможно, станут одними из самых передовых в мире. Это может быть прямым результатом более гибкого подхода. Может быть, на самом деле вопрос - не "можешь?" но "если Agile задерживает сложные системы, обеспечивает ли он более инновационный продукт в выигрыше?"
Agile в программном обеспечении и Agile в производстве действительно совсем другие, хотя они имеют сходные принципы и ценности.
Agile в производстве появился в Японии в 1950-х годах. Читайте на W.E. Deming и Toyota Production System, чтобы узнать больше. Это все о постоянном улучшении процесса воспроизведения продукта.
Agile в программном обеспечении, разработанном в начале 1990-х годов как модель быстрого развития. Все о постоянном улучшении продукта.
Конечно, вы можете построить самолет, используя Agile методы производства, я не сомневаюсь, что некоторые из них уже есть. Все, что построено в Японии, определенно будет таким, как производство Agile очень хорошо установлено там (оно преподавалось в начальных школах).
Вы не могли построить самолет, используя программные средства Agile, потому что вы не можете позволить себе быстро менять продукт - в программных изменениях и ошибках дешево, а воспроизведение бесплатное. Это не относится к авиации.
Вы можете спроектировать плоскость прототипа, используя что-то вроде программных средств Agile, но его нужно будет стандартизировать для воспроизведения (сама задача проектирования).
Как вы будете работать с помощью Test Driven Development? Будете ли вы автоматически строить и тестировать самолет на каждой итерации? Сможете ли вы построить десять минут? Как легко вносить изменения в самолет? Даже если вы действительно гибки в своем дизайне, некоторые компоненты необходимо отправить на специальные фабрики, чтобы не было немедленной обратной связи.
Из дизайна с использованием программного обеспечения САПР вам нужно сделать пресс-форму, взять кусок волокна, поместить его в самолет. И т.е. Здесь тривиальное изменение имеет нетривиальную стоимость. В Agile вы можете сделать очень мало изменений и протестировать, построить и готово к отправке через 20 минут. Если небольшие изменения дороги, то короткий цикл разработки и рефакторинг не будут столь полезными. Ваша обратная связь может занять больше недели, поэтому есть веская причина думать заранее, как в модели водопада. И каждая попытка имеет стоимость в физических материалах, если вы не программируете. Идея не нова. Плотники измеряют дважды. Программисты только первый код, а затем проверить.
В заключение. Могут быть некоторые сходства, но это окончательно будет одинаковым.
Toyota впервые разработала Lean Production, с которой последовали Agile методы. Для строительства аппаратного обеспечения самолета бережливое производство было бы способом, и для программного обеспечения была бы гибкой методологией.
Выберите нужные инструменты для работы.
Отличная книга о том, как TPS был создан и работает http://www.amazon.com/Machine-That-Changed-World-Production/dp/0060974176
Я думаю, что в этом случае вы думаете слишком много. Agile - это пробитие вещей в более управляемые части, а затем работа с этим. Вся идея Agile (в частности, XP) заключается в том, что вы сначала проводите тестирование, чтобы сократить количество ошибок, и потому что программное обеспечение самолета должно иметь очень высокий охват кода для его тестирования, он подходит довольно аккуратно, я думаю.
Вы не собираетесь "реорганизовывать" механику самолета, но вы будете настраивать их, если они небезопасны, и это для вас итеративный подход.
Я слышал о программном обеспечении управления воздушным движением, написанном Agile Methodologies, который продвигает его вперед.
Это взято из http://requirements.seilevel.com/blog/2008/06/incose-2008-can-you-build-airplane-with.html
***Actually, that’s not true,***
Мое первое предположение - это, вероятно, связано с некоторыми основными различиями между системами и разработкой программного обеспечения. Я собираюсь упростить это и просто сказать, что речь идет о масштабе. Системные проекты - это всего лишь надстройка программных и аппаратных проектов, интеграция и развертывание некоторой их комбинации. Группы людей, которые развертывают системные проекты, довольно велики. И многие из обсуждаемых здесь проектов предназначены для государственных или регулируемых систем, где требуется спецификация и прослеживаемость. Я мог видеть, как можно было бы разработать подмножества системных проектов с использованием гибких (чистых программных компонентов), но Im не убежден, что весь сквозной проект может. Чтобы представить это в контексте, представьте, что вы строите самолет - очень часто называемый тип системных инженерных проектов. Вы можете видеть, как это работает с помощью agile?
Весь скептицизм в стороне, я думаю, что итеративное развитие, безусловно, могло бы хорошо работать в системных проектах, и большинство людей здесь не будут спорить об этом. На самом деле, мне было бы очень приятно, если бы мы могли найти примеры гибкой работы над проектами в области систем, потому что чувство, которое я испытываю на конференциях по инженерным системам, - это стремление к более легким процессам.
Я решил провести небольшое исследование за стенами конференции, и я с трудом обнаружил замечательную статью по этой точной теме - "К Agile Systems Engineering Processes" доктора Ричарда Тернера из Консорциума систем и программного обеспечения, Статья очень хорошо изложена, и я настоятельно рекомендую ее прочитать. Он определяет, что такое гибкость и что он считает проблемой, почему большинство системных инженерных проектов не являются проворными. Например, он предполагает, что руководители и руководители программ склонны полагать, что задействованные команды имеют совершенные знания о системах, которые мы строим, поэтому мы можем планировать их заранее и работать над совершенным исполнением в отличном графике.
Agile может работать со сложными системами
Он говорит о том, как гибкие концепции могут работать в системных проектах. Вот несколько примеров, приведенных в его статье:
Обучение основано: традиционная V-модель подразумевает одноразовую поездку, подразумевая одно время для повторного изучения. Однако, возможно, модель может быть повторно интерпретирована, чтобы позволить ей выполнить несколько итераций.
Ориентация на клиента. Обычно процессы системного проектирования не поддерживают множественные взаимодействия с клиентом на протяжении всего проекта (только перед сбором требований). Тем не менее, он ссылается на исследование, в котором сообщается об известных проблемах с проблемами системных проектов. Поэтому, возможно, процессы должны быть адаптированы для обеспечения этого, в частности, позволяя им помогать определять приоритеты требований на всех проектах.
Короткие итерации: Итерации в значительной степени неслыханны, потому что V-модель является разовым прохождением жизненного цикла разработки. Тем не менее, итерации прототипирования посредством тестирования могут быть выполнены во многих случаях. Проблема заключается в доставке чего-то завершенного в конце каждой итерации. Он предполагает, что это не так важно для клиента при больших развертываниях, поскольку это снижает риск, проверяет требования и т.д. Это отличный момент, чтобы вспомнить пример самолета! Можем ли мы иметь уже рабочую часть самолета через 2 недели? Как насчет даже программного обеспечения для запуска подсистемы на самолете?
Собственность команды: системная инженерия очень управляется процессом, поэтому эта сложность. Д-р Тернер выдвигает идею о том, что, возможно, это позволит системным инженерам управлять им, а не процессом их вождения, но более неудобно для управления, может дать более эффективные результаты.
Существует такая история о заводе авиационных двигателей (сентябрь 1999 года). Их методы кажутся довольно проворными:
Да, вы могли бы это сделать. Если бы вы слишком внимательно следили за методами разработки Agile Software Development, это было бы астрономически дорогостоящим из-за различных затрат на деятельность.
Рассмотрим относительные затраты на проектирование и сборку. Если мы включим кодирование как часть процесса разработки программного обеспечения, то дизайн, безусловно, дорогая часть, а сборка смехотворно проста и дешева. Большинство Agile-проектов планируют выпустить как минимум несколько итераций. Таким образом, мы можем работать с небольшими итерациями с непрерывным процессом сборки. Не так просто, когда вам нужно собрать самолет раз в две недели. Хуже того, если вы на самом деле планируете "освободить" его. Вам, вероятно, понадобится, чтобы люди, отвечающие за летную годность и безопасность, также присоединились к Agile-процессу.
Мне бы очень хотелось увидеть, как он пытался.
Да, вы можете использовать гибкие методы для построения сложных систем, но я не знаю, буду ли я использовать его для этой конкретной системы.
Проблема с воздушными судами - проблема безопасности. Это означает, что необходимо принять все меры предосторожности: от правильной идентификации и интерпретации требований к проверке и проверке каждой отдельной строки кода.
Кроме того, формальные методы, вероятно, должны использоваться, чтобы убедиться, что система действительно безопасна, убедившись, что логика программирования звучит и удовлетворяет ее условиям должным образом.
Я уверен, что ответ не имеет значения. Даже если бы вы могли, вам не позволили бы. Слишком много требований безопасности. Вам даже не позволили бы разработать ПО для полетов с помощью Agile. Например, у вас нет спецификации требований к программному обеспечению (SRS) в Agile. Тем не менее, для любого программного обеспечения авионики на борту самолета, который может повлиять на безопасность полетов, вам понадобится SRS.
Конечно, можно реорганизовать плоскость.
Когда один рефактор, один изменяет исходный код, а не двоичные файлы. С плоскостью это точно одно и то же: один изменяет чертежи, а не сам самолет.