Процесс веб-девелопмента. Подход к разработке web-проекта | Организация процесса движения проекта

Автор Georgiy Dronov
Процесс веб-девелопмента. Подход к разработке web-проекта | Организация процесса движения проекта

Всем привет в этом видео.

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

Сколько будет стоить TZ определи границы дату с начальной версии сколько — это будет на какие модули должны быть включены дали делали TZ на основании.

Определи грубый оценку уже уже точно оценка проекта и соответственно после этого на основании оценки апреля этапы и двигались по этапам то есть. Вот И там пять этапов мы внедряем проект. Всё дальше уже сопровождение. Вот такая вот модель когда мы тратим виновата, но жестко задан следующим конечно какие-то там изменения могут быть мелкие правки сразу внедряются крупный идут. Как долго потом да. после реализации основной TZ вот модель есть свои плюсы. Когда у вас всё точно чётко. Когда у вас полностью есть понимание, что устал быть такое то есть заказчик чётко понимает, что он знает, что он хочет и вероятность изменения будет небольшая. А вот, но на практике. Как показала. Практика — это практически. Ну очень сложно реализуемо потому часто заказчики. Даже на это. ПТЗ много переделывают, что потом ещё больше то есть да то есть уже когда её про смотреть этапы расчета не думай твой мы вот сейчас думаю уже совсем по-другому давайте-ка — это уберём. А вот — это вот поставили начинается как в этих карта с изменением TZ — это как бы тоже не очень хорошо вот поэтому мы движемся в сторону аджайл то есть, что имеешь в виду по сути дела. В чём разница. Мы неопределяемым изначально жёсткий какой-то бюджет на весь проект мне определяем вообще в принципе TZ изначально. Полностью мы договариваемся общую группу оценки проекта, но — это не является обязательством да то есть мы даём техническую оценку то, что вот — это вот скорее всего не дарить на первую версию будет стоить стоп, но — это не факт совершенно — это именно оценка — это не обязательства вот. Даймон Q и дальше разработка по — это рация по этапам да то есть маленький в этом каждый этап начинается вернее перед этапом создается задание только на — это так то есть нет такого задачи создать полностью там всю систему мы определяем основные важные функции и элементы которые надо рисовать в этом. Это первый этап — это обычном создание просто статичного сайта с каким-то минимальным набором функций соответственно этап сдаётся плата и далее определяется, что в следующем является этапом вот таким образом идет постоянное внедрение функции в проект и сдача их последовательно и по сути дела у этого подхода нету как бы конца по-большому потому, что любой проект успешно. Да он может лучше развивается. То есть если он работает если в нём есть поезд или сидячий что-то дальше внедрить нет такой ситуации. Вот Всё мы внедрили всё. Вот всё работает — это вот нога. Да — это наверняка ничего менять не нужно даже уже когда вы внедряйте делаете там очередного этапа уже возникают новые идеи AutoCAD улучшить. Как можно сделать ещё удобнее поэтому. Ну и плюс всегда будет редизайн да то есть всегда какие-то элементы дизайна всегда хочется поменять застревает. Вот и соответственно — это тоже вот нюансы которые надо учитывать я хотел обратить в некоторые моменты в чём плюсы подхода да то есть ну во-первых я не. Давайте о чём. О чём с минусов. То есть у нас нет. Точно бюджета то есть мы не знаем. Точно конечно бюджет проекта на самом деле вы там сложно сказать потому, что мы понимаем, что любой проект будет опять же заработок. Мы даже вот сделали. ПТЗ большом. ГДЗ проект не понимаю, что всё равно подработки что-то не конечно бюджет на самом деле вот, а нельзя его определить потому что. Ну так вот конкретно. Вот из-за вот по нему можем оценить. А, что там дальше в голове у заказчика. Никто не знает никто не знает какая какая будет сложность ситуации там у неё на рынке коммерческие факторы и соответственно ну-ка потребности возникают совершенно невозможно предсказать. Вот — это главный минус, но он сказал, что такое минус. Ну который на самом деле. И там тоже присутствует в подходах самый главный плюс в том, что посадил вам можно будет менять по сути дела требования после каждой итерации то есть мы когда делаем классическом подходе датой экспериментальном обычном сразу и у нас нету посадил возможность изменить там следующий этап. А здесь мы определяем на основании текущей информации не начальная информация о текущей, что есть какой-то никак пользователей, что что нам нужно делать дальше посмотрим прилетят посадила далее мы делаем такую штуку потому, что то есть, но нам дали такую информацию сейчас, а вот очень удобно то есть потому, что мы знаем как нубу нас больше информации в текущий момент чем когда мы только начинаем проект. Ну я имею в первую очередь — это продукт оунер готовить тот кто делает заказчик. Скорее да то есть заказчик который который определяет развитие продукта есть у неё больше информации он может как можно ему двигателе в следующий момент — это быстрое внедрение то есть.

0 комментариев
0

Читайте также