Какие шаги составляют ваш процесс веб-разработки и сколько времени занимает каждый этап?

Question

Допустим, вы работаете над проектом 100 дней. Сколько дней займет каждый этап вашего процесса (анализ требований, спецификация и т. Д.)?

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

Большое спасибо!

EDIT:

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

EDIT2:

Как правильно заметила Хелен, на этот вопрос очень сложно ответить, поскольку проекты могут быть такими разными, как и команды. Чтобы сделать его более конкретным, скажем, у вас есть команда из четырех разработчиков - два из них для серверной работы, один для внешнего программирования и один для проектирования и html / css-кодирования (один член команды выступает в качестве проекта менеджер) и вы должны разработать сайт StackOverflow.com.

Answer 1

Мы выполняем Agile Scrum-проекты, поэтому обычно все эти действия выполняем параллельно. Поэтому, хотя я не могу ответить на ваш точный вопрос, я могу дать вам некоторые идеи о соотношениях, которые мы считаем эффективными:

4-5 разработчиков могут обслуживать один клиентский программист (html / css), один командный тестировщик и один дизайнер взаимодействия (работает с заказчиком над проектированием каркасов). Подобной команде обычно требуется 50% графический дизайнер для большинства приложений, но ваш пробег может варьироваться. Кроме того, есть менеджер проектов и множество других заинтересованных сторон, которые не являются частью основной команды разработчиков.

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

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

Answer 2

• Шаг 1: отказ
• Шаг 2: гнев
• Шаг 3: принятие

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

Answer 3

Я согласен со всеми, кто начинал в духе «Это зависит от проекта».

С другой стороны, я думаю, что есть последовательный процесс, которому можно следовать; только настройки процентов усилий, чтобы соответствовать проекту:

Как правило, я следую этим основным принципам:

1. Discovery - определение функции / функциональности системы. Самое простое (и самое худшее), что нужно сделать, это принять то, что просят, и идти с этим.
   Например, "building stackoverflow.com" является довольно широким запросом - и на самом деле это неправильный запрос. Проект должен начаться с "Мне нужно онлайн место, где программисты могут сотрудничать". Основываясь на одной вещи, которую вы пытаетесь решить, вы можете углубиться во все детали, которые вы хотите - например, как на вопрос будет дан ответ, задан, оценен и т. Д. Я думаю это самый важный шаг ! выход = требования / спецификация; Здесь можно спокойно провести 20/100 дней
2. Создание каркаса - здесь мне нравится использовать базовые HTML-страницы, paint.NET или даже конструкторскую бумагу и клей для макета каждого аспекта функциональности конечного сайта. Мне нравится использовать бумагу, потому что легко вносить изменения :) Пройдя этот процесс, вы заставляете задуматься практически обо всех аспектах взаимодействия с пользователем и можете гибко добавлять / удалять функции и корректировать свои требования по мере необходимости. Ваш клиент должен внести некоторые изменения, прежде чем вы посвятите много времени написанию кода. Дополнительным бонусом является то, что вы можете использовать пасту :) 10/100 дней
3. Внедрение / Тестирование - Я группирую реализацию И тестирование вместе, потому что я думаю, что близоруко разработать целый сайт без тестирования в процессе. (В то же время вам все еще нужен шаг 4). Это та часть, где резина отправляется в путь. Если вы правильно обработали свой клиент в шагах 1 и 2, вы будете приятно писать свой код без каких-либо изменений в последнюю минуту (или, по крайней мере, очень мало). Я стараюсь следовать общему набору шагов для реализации:
   • развитие данных (проектирование базы данных, разработка запросов, выборка данных)
   • платформа сайта (настройка среды (окружений); production, dev и qa)
   • интерфейсная структура (css, стандартные классы, стандартные структуры html)
   • начать кодирование! 55/100 дней
4. SQA - мы надеемся, что вы можете привлечь некоторые не вовлеченные стороны / конечных пользователей к тестированию приложения на ходу. Должны быть разработаны планы тестирования, чтобы было ясно, что следует тестировать и каковы желаемые результаты. Мне нравится использовать реальных людей для тестирования внешнего интерфейса; автоматизированные инструменты хороши для модулей кода / бэкэнда Это хорошее время, чтобы позволить клиенту наблюдать за прогрессом - у него должны быть очень ограниченные возможности для внесения изменений в этот момент. 10/100 дней
5. Медовый месяц доставки / пост-производства - вы создали его, протестировали и готовы к развертыванию. Получите код и позвольте клиенту играть. Вам не нужно много подправлять; но я уверен, что будут некоторые корректировки. 5/100 дней

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

Answer 4

Это действительно сложные вопросы. Чтобы дать несколько точную оценку соотношения времени, которое вам необходимо подать на каждый шаг - если мы применяем классический подход к проектированию, внедрению, тестированию и развертыванию - необходимо знать спецификацию и опыт участников проекта. Если вы возьмете книгу Макконнелла «Оценка программного обеспечения» (которую я настоятельно рекомендую), у вас есть глава об их исторических данных и о том, как использовать их для будущих проектов. Я не думаю, что у вас есть точные исторические данные предыдущих проектов - ну, у меня их нет - хотя я всегда напоминаю мне о записи их;) Поскольку наименьшие сбои или неопределенности на этапе проектирования являются наиболее важными, требуется много времени, чтобы определить, что вы хотите сделать . Убедитесь, что все понимают это одинаково, и запишите это. Короче говоря, я бы выделил 50% - 75% времени на проектирование (если 75% это будет включать прототип, чтобы очистить все неопределенности) и равные части в реализации и тестировании. Если вы используете TDD, вы бы немного смешали дизайн и тестирование, чтобы взять немного фазы проектирования и добавить ее к фазе тестирования.

Answer 5

Просто чтобы прояснить - вы в основном ограничивает время своей работы - что напрямую связано с фиксированным бюджетом (4 разработчика x $ x в день x 100 дней - при условии, что это 100 дней, а не 100 дней работы) ). Если это так, то в среднем. вы бы потратили:

• 25% предварительное планирование, которое включает в себя область применения, разработку спецификаций, технологический подход, логистику (компьютеры, серверы, рабочее пространство), сбор ресурсов.
• 50% разработка - разработка тестового примера (TDD), разработка и реализация схемы, внешнее кодирование, внутреннее кодирование, развертывание
• 15% Тестирование - основные действия по устранению неполадок
• 10% накладных расходов / управление - управление проектом, связь и координация.

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

Answer 6

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

Когда мы решали новый проект, «сбор требований» обычно проводился на доске днем, обычно с кем-то из отдела, который больше всего использовал новое программное обеспечение. Был небольшой предварительный дизайн и много ре-факторинга и переписывания. Мы были очень довольны этим и создали около 100 000 строк кода, которые хорошо спроектированы и стабильны.

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

Answer 7

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

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

Answer 8

Только что нашел эту ветку , которая отвечает на вопрос "что" на мой вопрос. По крайней мере, частично.

Answer 9

1. Составление списка потребностей клиента 1-2 дня
   Это зависит от клиента и того, что ему нужно, и насколько хорошо он подготовлен.
2. Дизайнеры делают первые наброски 2-3 дня
   Здесь происходит небольшое ветвление, так как 2 и 3 происходят одновременно.
3. Программисты создают любую функциональность, которой еще нет в нашей существующей системе 1 день - 1 месяц
   Это зависит от клиента и того, что ему нужно больше всего на свете.
   Это также даст только функциональный код.
4. Повторяйте шаги 2 и 3, пока клиент не будет удовлетворен общим ощущением того, что у нас есть.
   Может быть 1 итерация, может быть 100 (маловероятно, если к 10 мы не сможем сделать их счастливыми, мы отправим их куда-нибудь еще.
   
5. Построить окончательный дизайн за 1-5 дней
   Это последний, без ошибок, действительный CSS / HTML / JS, все кросс-браузер и т.д.
   
6. Создание окончательного функционала 2-3 дня
   Этот код "идеален", он работает на 100%, он симпатичен, известных ошибок нет, и разработчики рады его отправить
   Это и Шаг 5 происходят одновременно.
7. Развертывание 10 секунд.

Затем через 2 недели, 2 месяца и 6 месяцев мы делаем обзор, чтобы убедиться, что проблем не было.

Так что, если вы пропустите обзор, обычно это занимает 8-20 дней, подумайте, как вы справитесь с этим в течение 100 дней.

---

Если мы просто создаем приложение (или расширяем его) для клиента, мы потратили бы 2-3, определяя ТОЧНО то, что им нужно, сколько бы времени ни потребовалось для его создания.