Прогнозирующий по сравнению с Реактивной [закрытой] разработкой программного обеспечения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

обратное поведение

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

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

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

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

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

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

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

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