Predictive vs Реактивный дизайн программного обеспечения

Question

Я знаю, что для меня я впервые начал работу с методом водопада управления проектами, и вместе с тем я пошел с прогностическим подходом к разработке программного обеспечения. В этом я имею в виду, что у нас были огромные пакеты документации, UML, схемы баз данных, словари данных, рабочие процессы, диаграммы активности и т. Д.

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

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

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

вопрос: Зачем кому-то использовать водопад над какой-то гибкой способностью со всем исследовательским подходом? Каковы сильные аргументы в пользу использования водопада над гибким?

Answer 1

Мой босс говорит мне.

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

Answer 2

Когда я начал программировать (с COBOL не менее), водопад был «новым» подходом. Сегодня я скажу вам, что я использую водопадную гибкую методологию. Для более крупных систем я считаю, что запуск типа водопада лучше всего работает. Не создавать огромные документы (это пустая трата времени IMO), а скорее предпринять некоторые шаги, такие как создание прототипа пользовательского интерфейса и/или использования, чтобы разобраться с бизнес-проблемами. Как только мы будем комфортно, мы сталкиваемся с проблемой, и у нас есть четкое понимание, мы переходим в гибкий режим разработки.

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

Не принимать сторону, но в любом случае любое исследование будет в лучшем случае ненаучным.

Вы говорите (курсив мой)

вопрос: Почему бы кто-то использовать водопад над какой-либо форме гибкой со всеми научно-исследовательской поддержки гибкой? Каковы сильные аргументы в пользу использования водопада над гибким?

, но не ссылки на какие-либо исследования.

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

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

Answer 7

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

Мой опыт с подвижным не был очень положительным. Справедливости ради следует отметить, что я использовал его в корпоративной среде, которая приложила все усилия к тому, чтобы «проворствовать», ожидая, что наш менеджер подготовит долгосрочные контрольные точки и результаты.

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

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

Answer 8

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

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

P.s. нет такой вещи, как гибкая и фиксированная цена. Не в классическом способе они обычно продают метод. См http://martinfowler.com/bliki/FixedPrice.html

Answer 9

ретроактивного поведение

Answer 10

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

Answer 11

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

Опыт показывает, что очень сложно прийти к полному пониманию проблемы и что, если принять некоторые меры предосторожности (например, Unit Testing), это может стать намного дешевле. Поэтому, если вы столкнулись с проблемой, когда некоторые из гибких помещений не выдерживают, другие подходы могут стать осуществимыми снова. Между Водопадом и Agile существует, по крайней мере, спиральное развитие, которое - это то, что мы практикуем.

Answer 12

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

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

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

Answer 13

Документация, созданная во время процесса водопада, позволяет использовать много CYA. Вы можете указывать пальцы, когда проект уходит с рельсов. Очень немногие руководители будут в порядке: «О, хорошо, я думаю, что проект ушел от нас! Ну, по крайней мере, мы узнали рано, никакого вреда не фол!»

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

Answer 14

Вы должны быть достаточно склонны к поставке товара. Вы должны быть достаточно реактивны, чтобы справляться с проблемами.

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

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

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

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

Answer 15

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