Comments 45
«Разработка требований» режет слух, не лучше ли говорить «сборка требований»?
Нет не лучше.
В данном случае имеется в виду «разработка документа(ов) с требованиями к ПО»
В данном случае имеется в виду «разработка документа(ов) с требованиями к ПО»
Я сознательно употребляю термин «разработка требований», поскольку аналитикам и архитекторам часто приходится приложить немалые усилия для того, чтобы выяснить реальные потребности заказчика и сопоставить их с потребностями бизнеса своей организации.
Если этого не сделать, то можно попасть в две крайности: либо в список требований будет содержать много никому не нужных функций, которые придётся реализовать, отладить и сопровождать, либо список окажется не полным, и в итоге ПО окажется никому не нужной, а репутация исполнителя — сильно подмоченной. То и другое выливается в значительно (на порядок) бОльшие затраты, чем затраты на качественную разработку требований в начале проекта.
В большинстве проектов, где аналитики просто занимаются «сбором требований», исполнитель умудряется попасть в обе эти крайности одновременно.
Если этого не сделать, то можно попасть в две крайности: либо в список требований будет содержать много никому не нужных функций, которые придётся реализовать, отладить и сопровождать, либо список окажется не полным, и в итоге ПО окажется никому не нужной, а репутация исполнителя — сильно подмоченной. То и другое выливается в значительно (на порядок) бОльшие затраты, чем затраты на качественную разработку требований в начале проекта.
В большинстве проектов, где аналитики просто занимаются «сбором требований», исполнитель умудряется попасть в обе эти крайности одновременно.
А где же Agile проектирование, Экстрема́льное программи́рование и ему подобные? По сути надо было написать «Обзор водопадной модели процесса разработки программного обеспечения». Вообще-то водопадная (каскадная) модель по-моим наблюдениям уже даже не самая популярная и многими считается устаревшей.
Многими заказчиками или программистами и архитекторами?
И теми и другими, если говорить о зарубежных компаниях. Ради интереса поищите вакансии java разработчик в Европе/США, в доброй половине вы увидите требования знания Agile или XP программирования, что как бы намекает на что сейчас мода.
В Европе/США вполне возможно, но вот у нас я слабо могу себе представить тендер на разработку ПО по методологии Agile…
С играми похожая история, я бы не стал покупать диск с первой итерацией новой игры на консоль…
С играми похожая история, я бы не стал покупать диск с первой итерацией новой игры на консоль…
тендер на разработку ПО по методологии Agile
А что есть тендер на разработку ПО по каскадной методологии? Методология это процесс взаимодействия с заказчиком и выдачи релизов, а не тендеров. На самом деле, процесс непрерывных уточнений у заказов и показов некоторых прототипов достаточно часто встречается (при том что ни исполнитель ни заказчик не подозревают что работают по Agile модели).
С играми похожая история, я бы не стал покупать диск с первой итерацией новой игры на консоль…
Заказчик в методологии Agile не обязательно покупатель, это может быть преальфа тестер, задачей которого определить «играбельность» каждой итерации.
P.S. На самом деле, методология проектирования не имеет отношения ни к тендерам, ни к продажам.
UFO just landed and posted this here
Это водопад, никак не Agile.
Может просто потому, что заказчик вообще не сильно в курсе существования Agile, а исполнитель не объясняет этому заказчику все плюсы итеративного подхода и риски водопадного?
UFO just landed and posted this here
Нет, как правило дело не в этом. Просто в большей своей массе российские компании имеют понятие «бюджета» и его выделения, а соответственно и «fixed price», что в итоге приводит к обязательному наличию «ТЗ». Все эти " волшебные слова" фактически исключают возможность работы по agile-методологиям. И даже если команда «внутри» работает гибко, то для заказчика это все равно каскад. Крайне мало заказчиков с которыми нам приходилось работать готовы использовать agile и time&materials. Причём чем крупнее заказчик, тем меньше на это шансов.
Интересная история от Фаулера на эту тему www.martinfowler.com/bliki/ScopeLimbering.html
С играми похожая история, я бы не стал покупать диск с первой итерацией новой игры на консоль…
1. Бывают ли игры кроме тех, которые распространяются на дисках под консоль? Я вот, например, слышал что бывают мобильные и браузеры игры.
2. Поищите описание какого-нибудь agile процесса разработки например наберите «scrum guide» в поисковике. Поищите там слово release — как правило релизится результат не каждой итерации или методология допускает такое.
Тренеры Олег и Сергей Дмитриевы рассказывали про свой успешный опыт участия в гос тендерах на agile разработку в ЕС, но там условия тендера отличались от наших гос проектов.
Гибкая методология — вполне применимая модель разработки ПО. Если заказчику нужна автоматизация критичных бизнес-процессов, но не по «высеченому в камне» тех заданию, а когда в процессе разработки и эксплуатации меняются требования к системе, область новая, много рисков и не учтенных факторов. Когда компания сама получает доход от такой автоматизации, а не делает ее для «галочки».
Agile методология — просто инструмент, который имеет свои условия применения и область в которой он успешно решает задачи.
Вряд ли удобно будет забивать гвозди отверткой или микроскопом. И использование только техник из agile не гарантирует что процесс разработки сразу становится гибким.
Поддерживает более простую модель, учитывающую изменение требований к системе, более жизненную приоритезацию задач, возможность быстро получить minimum viable product (MVP). Но в этом случае нельзя жестко фиксировать сразу бюджет, объем работ, время разработки и качество, все равно в сложном проекте это не угадаешь.
Гибкая методология — вполне применимая модель разработки ПО. Если заказчику нужна автоматизация критичных бизнес-процессов, но не по «высеченому в камне» тех заданию, а когда в процессе разработки и эксплуатации меняются требования к системе, область новая, много рисков и не учтенных факторов. Когда компания сама получает доход от такой автоматизации, а не делает ее для «галочки».
Agile методология — просто инструмент, который имеет свои условия применения и область в которой он успешно решает задачи.
Вряд ли удобно будет забивать гвозди отверткой или микроскопом. И использование только техник из agile не гарантирует что процесс разработки сразу становится гибким.
Поддерживает более простую модель, учитывающую изменение требований к системе, более жизненную приоритезацию задач, возможность быстро получить minimum viable product (MVP). Но в этом случае нельзя жестко фиксировать сразу бюджет, объем работ, время разработки и качество, все равно в сложном проекте это не угадаешь.
Не угадаешь, но всем хочется максимального контроля за бюджетом (по факту точную цифру ещё до начала работ). Поэтому и получается, что выбирая между гибкостью (agile, time&materials etc) и контролем бюджета (waterfall, fixed price), наши компании выбирают второе. В такой схеме все риски «не угадывания» виснут на исполнителе и без монолитного ТЗ можно просто пролететь. Так и живём.
Многими всеми. Только они внимание акцентирует на разном.
Согласен. Но я не случайно написал в статье, что схема процесса является результатом обобщения моего личного опыта. Так сложилось, что для заказчиков, с которыми я работаю, и для моего руководства указанная схема оказалась наиболее удобной. Я не говорю о том, что мой обзор полный. Напротив, цель статьи — указать на особенности процесса разработки, с которыми мне приходилось сталкиваться.
Буду признателен, если Вы укажете на какие-либо нюансы, которые могли бы улучшить приведённую мной схему, или расскажете о схеме, которую используете Вы.
Буду признателен, если Вы укажете на какие-либо нюансы, которые могли бы улучшить приведённую мной схему, или расскажете о схеме, которую используете Вы.
для моего руководства указанная схема оказалась наиболее удобной
Какие альтернативы рассматривались и почему не подошли?
Пример заказного ПО. Системное ПО для обеспечения процесса прогнозирования Единой энергосистемы России. Рассчитывается прогноз по всем типам оборудования, участвующим в генерации, передаче и потреблении электроэнергии, с учётом международных перетоков. Система чрезвычайно высоконагруженная, требует высокой точности вычислений, высочайшей надёжности: от её работы зависит, насколько точно будет сбалансировано производство электроэнергии и её потребление. Чтобы создать систему, пришлось изучать специфику каждого типа оборудования, специфику управления ими, фактически, специфику работы специалистов, управляющим энергосистемой. Архитекторам и программистам пришлось бороться за каждый байт и за каждый такт процессора. Нужно было учитывать специфику виртуализации вычислительных ресурсов. И ещё многое другое. Заказчик при этом не может надолго предоставить нам своих диспетчеров: они, поверьте, очень занятые люди. Всю систему нужно поставлять только целиком: никому не нужно ПО, рассчитывающее только 99% модели. Моя схема сработала: мы выпустили ПО в срок (хотя опытная эксплуатация несколько затянулась: был ряд моментов. которые можно было отследить только в боевых условиях).
Пример инвестиционного ПО. Мы долгое время разрабатывали одну комплексную систему безопасности. Под моим руководством было выпущено последовательно четыре версии этой системы. Она использовалась в мэрии Москвы, АФК «Система», ВГТРК и ещё тысячах организациях, начиная с нашего собственного офиса. Первая версия была не очень успешной, но у нас была стратегия развития, которая позволила нам успешно захватить рынок. В тот момент, когда Россию накрыл кризис 2008-2009 года, мы не только не потеряли доходы, но и получили новый сегмент: бизнес-центры решили вкладывать в нашу систему на пике кризиса, хотя раньше не были на это готовы. Моя схема сработала.
Мы годами оттачиваем свои процессы. У нас много проектов, и мы гордимся, что наши продукты работают, а наши заказчики рекомендуют нас своим партнёрам.
Я не против гибкой методологии. Но я хочу говорить о том, что работает на практике для действительно сложных систем. Мой опыт двадцатилетней работы показывает, что приведённая в статье схема точно работает. И она для наших проектов достаточно гибкая.
Пример инвестиционного ПО. Мы долгое время разрабатывали одну комплексную систему безопасности. Под моим руководством было выпущено последовательно четыре версии этой системы. Она использовалась в мэрии Москвы, АФК «Система», ВГТРК и ещё тысячах организациях, начиная с нашего собственного офиса. Первая версия была не очень успешной, но у нас была стратегия развития, которая позволила нам успешно захватить рынок. В тот момент, когда Россию накрыл кризис 2008-2009 года, мы не только не потеряли доходы, но и получили новый сегмент: бизнес-центры решили вкладывать в нашу систему на пике кризиса, хотя раньше не были на это готовы. Моя схема сработала.
Мы годами оттачиваем свои процессы. У нас много проектов, и мы гордимся, что наши продукты работают, а наши заказчики рекомендуют нас своим партнёрам.
Я не против гибкой методологии. Но я хочу говорить о том, что работает на практике для действительно сложных систем. Мой опыт двадцатилетней работы показывает, что приведённая в статье схема точно работает. И она для наших проектов достаточно гибкая.
Спасибо. Мне кажется, надо такое вставлять в статью.
«Всю систему нужно поставлять только целиком: никому не нужно ПО, рассчитывающее только 99% модели.»
А нельзя как-то по другому композировать. Например «ПО рассчитывающее 100% модели, но только для конкретного подразделения» или «По, расчитывающее 90% модели, а 10% расчитывается так же как и сейчас».
А какие не-agile методологии вы рассматривали?
«Всю систему нужно поставлять только целиком: никому не нужно ПО, рассчитывающее только 99% модели.»
А нельзя как-то по другому композировать. Например «ПО рассчитывающее 100% модели, но только для конкретного подразделения» или «По, расчитывающее 90% модели, а 10% расчитывается так же как и сейчас».
Я не против гибкой методологии.
А какие не-agile методологии вы рассматривали?
Спасибо. Мне кажется, надо такое вставлять в статью.
Да, учту это на будущее :)
А нельзя как-то по другому композировать.
Композировать получилось. Но не разбитием модели: она теряет смысл при малейшей потере целостности.
Мы применили известный подход многоэтапной поставки. Плюс некоторые наши практические наработки.
Грубо говоря, в данном проекте первый этап — фундаментальные функции, на которые опирается модель (тут был почти чистый scrum, поскольку вёлся эвристический поиск технологических подходов, способов обхода ограничений среды разработки и выполнения и прочая исследовательская работа, но при этом всегда вёлся контроль за превышением рамок, заранее определённых для задач этого этапа). Второй этап — полностью реализованная модель (тут гибкость уже стала отжирать неоправданно много времени и сил, требования и технологии были полностью определены ранее). Третий — прикладные надстройки над моделью (тут тоже гибкость была ни к чему). К концу любого этапа система была полностью рабочей. Первая фактическая поставка была на втором этапе.
На всех этапах разработчикам нужна была целостная концепция системы и единое качественное архитектурное решение. Опытная эксплуатация тоже была возможна только для полностью завершённой системы, иначе диспетчеры просто не могли её проверить, т.к. критерием готовности системы было совпадение наших результатов с теми, которые рассчитывались по старой технологии, с соблюдением заданных нам жёстких ограничений на время расчёта и используемые ресурсы.
Таким образом, гибкие методологии можно использовать, но на определённых этапах и не теряя фокус с цели и задач проекта в целом. Но гибкость процесса в сложном проекте начинает изматывать людей и забирать слишком много времени. Поэтому там, где гибкость не требуется, от неё нужно отказываться.
Я бы сказал, что в данном проекте схема процесса в целом была наиболее близка к RUP с жёстким контролем концепции проекта, но со своей спецификой.
А чем Agile не вписывается в показанные модели? Там же есть итеративность. Agile-же вообще скорее про ценности, а не про то, что нет структурированного подхода :)
Поправьте меня, если ошибаюсь, но разве цикл разработки в общем виде для данной модели не «Сбор требований -> Анализ -> Проектирование -> Разработка -> Тестирование -> Внедрение»?
Не вижу списка источников и списка проанализированных разновидностей процессов. Если автор наблюдал эти процессы своими глазами, то хотелось бы примеров и ссылок компании. Если автор рассматривал процессы как они описаны в литературе, то хотелось бы ссылок на литературу.
Статья — обобщение моего опыта в надежде, что это поможет кому-то из моих коллег. Поэтому списка литературы не даю.
Примеры указал в ответе на один из комментариев выше. Но детально их раскладывать в статье, посвящённой только «верхнеуровневому» обзору используемого мной процесса, считаю, неуместным. Чтобы такой пример в статье был полезен, мне бы пришлось углубляться в каждый этап процесса, и тогда вместо статьи получилась бы увесистая книга.
Примеры указал в ответе на один из комментариев выше. Но детально их раскладывать в статье, посвящённой только «верхнеуровневому» обзору используемого мной процесса, считаю, неуместным. Чтобы такой пример в статье был полезен, мне бы пришлось углубляться в каждый этап процесса, и тогда вместо статьи получилась бы увесистая книга.
Спасибо за примеры. Просто с точки зрения читателя, перво-наперво интересно почему я должен доверять данной информации. Это может быть либо авторитет автора либо ссылки на источники.
Я думаю, уместно вкратце рассказать об опыте и сделанных проектах (например, так как вы сделали в коментарии) и про то, какие варианты процессов разработки были рассмотрены и почему не подошли.
Я думаю, уместно вкратце рассказать об опыте и сделанных проектах (например, так как вы сделали в коментарии) и про то, какие варианты процессов разработки были рассмотрены и почему не подошли.
существует несколько видов программного обеспечениябелое, пушистое, теплое и жаренное. Иногда белое бывает пушистым, теплое — жаренным. Тем не менее
остановлюсь только на различиях именно самого процесса касаемо разных видов ПО.Пушистое отличается от белого наличием форков.
Теплое не отличается от пушистого, но имеет ограничения.
Жаренное отличается от теплого особенностями.
Куда вы отнесете заказную разработку прошивки для игровой приставки, с разными аппаратными версиями? или это будет пятый тип «шуршащее»?
Дочитал абзацы про виды ПО и дальше читать не стал. Автор не владеет предметной областью.
Жирный минус.
Жирный минус.
Коллеги, я стал программистом не потому, что мне нравятся черно-серые квадраты, соединенные линиями. Несколько мрачное ощущение. Ничего нового для себя не увидел. Вы не перепутали выражения «разработка по» и «управление проектом»? Как программисту мне эта статья никак не помогает. Если вы действительно хотели затронуть тему разработки, то обсудили бы какую-нибудь комбинацию репозиториев и систем сборки, например, habrahabr.ru/post/75990. Там со знанием дела человек рассказывает, как он управляет проектами на уровне исходников. Причем мне кажется, актуальность эта статья не потеряла. С тех времен прошло уже 6 лет, появились bower, grunt, например, для упрощения разработки под web, хорошо подрос maven для джавистов, nuget для visual studio и прочее или полезное или специфическое. А вы рассказываете так, как я слышал это 20 лет назад в университете. Кстати, некоторые процессы отображаются другими геометрическими фигурами. )))
Срочно исправляйтесь!!!
Срочно исправляйтесь!!!
И не подумаю ;)
Серые квадраты нарисованы для тех, кто отвечает за организацию процесса разработки программного обеспечения. Программистам обычно эти схемы не показывают, потому как активность программистов — несколько точек в одном из этих серых квадратов.
Серые квадраты нарисованы для тех, кто отвечает за организацию процесса разработки программного обеспечения. Программистам обычно эти схемы не показывают, потому как активность программистов — несколько точек в одном из этих серых квадратов.
Программистам обычно эти схемы не показываютПозвольте, а что тут секретного или непонятного? У разработчиков в голове схемы и посложнее бывают.
Вот ещё момент из вашей статьи:
Кроме того, пользователи игровых программ, даже столкнувшись с ошибкой в игре, очень редко загружают обновлённую версию
Лично я не большой любитель игр, но вот на ipad тащусь от одной глупой casual игры (hill climb). Они периодически выпускают обновления, добавляя новый уровень или какой-либо элемент игры, а заодно исправляя ошибки. Я даже жду их обновления. Так что я не глупый пользователь, который не загружает обновлений.
Отмечу, что рассматриваемая здесь схема процесса является результатом обобщения моего личного опыта разработки различных программных средств.
Можно узнать, о чём идёт речь? Что за проекты из которых вы вынесли такие схемы, ваше участие в проектах?
Вы не перепутали выражения «разработка по» и «управление проектом»?
Ничего не перепутано у автора, путаете вы. Здесь «технология разработки ПО», а не «технологии в программировании».
Выработка тербований, проектирование, документирование, поддержка, само написание кода — все входит в «процесс разработки ПО».
А вы рассказываете так, как я слышал это 20 лет назад в университете.
Потому что оно не поменялось. Много чего добавили и расширили, но основа та же. Хотя появились и другие модели. Но то что вы описали про сборку/репозитории — это совсем из другой оперы.
Здесь «технология разработки ПО», а не «технологии в программировании».
Выработка тербований, проектирование, документирование, поддержка, само написание кода — все входит в «процесс разработки ПО»
И что из перечисленного вами не должен делать программист или другой участник команды, который имеет отношение к коду? По мне так даже программист должен словами написать в коммите, что он закодировал, а ещё лучше писать документацию, что сделано. Это можно делать в конце дня и это не занимает больше 10-15 минут времени в день. А другим проще будет понять, что делает сосед. Всё-таки программы пишутся для людей и именно другие люди должны понимать, что сделано.
Но то что вы описали про сборку/репозитории — это совсем из другой оперыВсе слова и договорённости должны каким-то образом учитываться в коде и попадать в сборку. Или нет?
Это обычная путаница (и холивор) между «программист» и «разработчик ПО».
В микроскопической команде все возможно. В крупных проектах создание ТЗ, проектирование, написание кода, тестирование и документация выполняются разными отделами, не то что людьми.
То, о чем вы говорите — про коммиты, «систему сборки» и пр — это уровень только «написание кода». То, что осуждается в статье — все стадии, и помянутые системы сборки — только малая часть.
Всё-таки программы пишутся для людей и именно другие люди должны понимать, что сделано.
В микроскопической команде все возможно. В крупных проектах создание ТЗ, проектирование, написание кода, тестирование и документация выполняются разными отделами, не то что людьми.
То, о чем вы говорите — про коммиты, «систему сборки» и пр — это уровень только «написание кода». То, что осуждается в статье — все стадии, и помянутые системы сборки — только малая часть.
А на каком этапе нужно собственно код писать?
Это было в Симпсонах^W^W у Джоэля: www.joelonsoftware.com/articles/FiveWorlds.html
Занимаюсь разработкой 16 лет. За это время удалось поработать в разных отраслях, в разных компаниях, на разных должностях.
Впечатление от статьи скептическое. Даже если это было попыткой осветить процессы совсем теоретически — по факту ни одного «гола».
Впечатление от статьи скептическое. Даже если это было попыткой осветить процессы совсем теоретически — по факту ни одного «гола».
Для того, чтобы учесть замечания, высказанные здесь коллегами, и лучше связать материал с новой статьёй «Подготовительный этап разработки программного обеспечения», я несколько изменил текст.
Спасибо всем за конструктивные замечания!
Спасибо всем за конструктивные замечания!
Sign up to leave a comment.
Обзор процесса разработки программного обеспечения