Какие шаги составляют ваш процесс веб-разработки и сколько времени занимает каждый этап?
Допустим, вы работаете над проектом 100 дней. Сколько дней займет каждый этап вашего процесса (анализ требований, спецификация и т. Д.)?
Меня также интересует соотношение конкретных действий на каждом этапе, таких как написание тестов, внутреннее кодирование, интерфейсное кодирование, визуальный дизайн, проектирование баз данных и т. Д.
Большое спасибо!
РЕДАКТИРОВАТЬ:
Просто чтобы прояснить ситуацию, я не говорю о дизайне веб-сайтов - меня интересует более "серьезная" веб-разработка, такая как пользовательские бизнес-приложения. Я знаю, что все зависит от специфики каждого проекта, однако я предполагаю, что отношения могут быть примерно одинаковыми от проекта к проекту.
EDIT2:
Как правильно заметила Хелен, на этот вопрос действительно сложно ответить, поскольку проекты могут быть такими разными, как и команды. Чтобы сделать его более конкретным, скажем, у вас есть команда из четырех разработчиков - двое из них для серверной работы, один для внешнего программирования и один для проектирования и html/css-кодирования (один из членов команды выступает в качестве проекта менеджер), и вы должны разработать сайт Stackru.com.
9 ответов
Мы выполняем Agile Scrum-проекты, поэтому обычно все эти действия выполняем параллельно. Поэтому, хотя я не могу ответить на ваш точный вопрос, я могу дать вам некоторые идеи о соотношениях, которые мы считаем эффективными:
4-5 разработчиков могут обслуживать один клиентский программист (html/css), один командный тестировщик и один дизайнер взаимодействия (работает с заказчиком над проектированием каркасов). Подобной команде обычно требуется 50% графический дизайнер для большинства приложений, но ваш пробег может варьироваться. Затем есть менеджер проекта, и есть множество других заинтересованных сторон, которые не являются частью основной команды разработчиков.
В команде разработчиков, как правило, есть пара разработчиков, которые со всей остротой относятся к разработке на стороне клиента и схожим количеством на стороне. Это штатное расписание также, как правило, отражает использование ресурсов;) Тестирование является неотъемлемой частью разработки, а также усилий коллективного тестировщика.
Ваши местные условия могут, конечно, отличаться, но эти цифры просто дать вам некоторое представление.
- Шаг 1: отказ
- Шаг 2: гнев
- Шаг 3: принятие
Время выполнения каждого шага различно для всех участников команды.
Я согласен со всеми, кто начинал в духе "Это зависит от проекта".
С другой стороны, я думаю, что есть последовательный процесс, которому можно следовать; только настройки процентов усилий, чтобы соответствовать проекту:
Как правило, я следую этим основным принципам:
- Обнаружение - определение функции / функциональности системы. Самое простое (и худшее), что нужно сделать, это принять то, что просят, и идти с этим.
Например, "building stackru.com" является довольно широким запросом - и на самом деле это неправильный запрос. Проект должен начинаться с "Мне нужно онлайн место, где программисты могут сотрудничать". Основываясь на одной вещи, которую вы пытаетесь решить, вы можете углубиться во все детали, которые вы хотите - например, как будет дан ответ на вопрос, задан, оценен и т. Д. Я думаю, что это самый важный шаг! выход = требования / спецификация; Здесь можно смело проводить 20/100 дней - Каркас - это то, где мне нравится использовать базовые HTML-страницы, paint.NET или даже конструкторскую бумагу и клей, чтобы макетировать каждый аспект функциональности конечного сайта. Мне нравится использовать бумагу, потому что в нее легко вносить изменения:) Пройдя этот процесс, вы заставите задуматься практически обо всех аспектах пользовательского опыта и сможете гибко добавлять / удалять функции и корректировать свои требования по мере необходимости. Ваш клиент должен внести некоторые изменения, прежде чем вы посвятите много времени написанию кода. Дополнительным бонусом является то, что вы можете использовать пасту:) 10/100 дней
- Внедрение / Тестирование - я объединяю реализацию и тестирование вместе, потому что считаю недальновидной разработку целого сайта без тестирования. (В то же время вам все еще нужен шаг 4). Это та часть, где резина отправляется в путь. Если вы правильно обработали свой клиент в шагах 1 и 2, вы будете приятно писать свой код без каких-либо изменений в последнюю минуту (или, по крайней мере, очень мало). Я стараюсь следовать общему набору шагов для реализации:
- развитие данных (дизайн БД, дизайн запросов, пример настройки данных)
- каркас сайта (настройка среды (окружений); production, dev и qa)
- структура переднего плана (css, стандартные классы, стандартные структуры html)
- начать кодирование! 55/100 дней
- SQA - мы надеемся, что вы сможете привлечь сторонних и конечных пользователей к тестированию приложения на ходу. Должны быть разработаны планы тестирования, чтобы было ясно, что следует тестировать и каковы желаемые результаты. Мне нравится использовать реальных людей для тестирования внешнего интерфейса; автоматизированные инструменты хороши для модулей кода / бэкэнда. Это хорошее время, чтобы позволить клиенту видеть, как что-то происходит, - у него должна быть очень ограниченная возможность вносить изменения в этот момент. 10/100 дней
- Медовый месяц доставки / пост-производства - вы создали его, протестировали и готовы к развертыванию. Получите код и позвольте клиенту играть. Вам не нужно много подправлять; но я уверен, что будут некоторые корректировки. 5/100 дней
Часть этого кажется идеалистической; но вы будете удивлены, как быстро вы сможете отправить свое приложение, если у вас есть хорошо продуманная, хорошо разработанная спецификация.
На этот вопрос невозможно дать содержательный ответ. Соотношения не будут даже примерно одинаковыми от проекта к проекту. Для некоторых проектов визуальный дизайн практически не имеет значения (при условии, что он более или менее работает), но база данных является критической и сложной. Для других это все для обеспечения беспрепятственного взаимодействия с большим количеством полезных вещей AJAX и других приятных глаз, но основные данные тривиально просты в организации и хранении.
Похоже, вы думаете в основном о проектах с одним человеком, но для более крупных команд также важен размер и настройка команды, а также процесс разработки.
Просто чтобы прояснить - вы в основном ограничивает время своей работы - что напрямую связано с наличием фиксированного бюджета (4 разработчика x $x в день x 100 дней - при условии, что это 100 дней, а не 100 дней работы). Если это так, то в среднем. вы бы потратили:
- Предварительное планирование на 25%, которое включает в себя область применения, разработку спецификаций, технологический подход, логистику (компьютеры, серверы, рабочее пространство), сбор ресурсов.
- 50% разработка - разработка тестового примера (TDD), разработка и реализация схемы, кодирование внешнего интерфейса, кодирование внутреннего интерфейса, развертывание
- 15% тестирование - основные действия по устранению неполадок
- 10% накладных расходов / управление - управление проектом, коммуникация и координация.
Очень грубая оценка - многие "области", которые необходимо учитывать, включая навыки / зрелость ресурсов, используемые технологии, расположение ресурсов (одна комната или по всей стране), уровень требований и т. Д. Использование ресурсов, ориентированных на конкретные навыки, позволит планировать сложнее, так как вам могут потребоваться ресурсы для выполнения нескольких ролей - одним из них может быть назначение 3 универсалов, которые могут помочь в спецификации / разработке / планировании, и одного технического мастера, который обеспечит правильную настройку платформы и базы данных (ключ к успеху, как только вы иметь хорошие как можно требования)
Возможно, мы необычный девелоперский магазин. Все наше существование (по крайней мере в рабочее время) - это сбор требований. Разработчики обязаны работать в любом другом отделе. Будь то ответ на телефонный звонок послепродажной поддержки (и борьба с программным обеспечением CRM), вождение вилочного погрузчика на складе (и борьба с мобильными терминалами) или упаковка ящиков на станции отгрузки (и борьба с запутанными накладными).
Когда мы занимались новым проектом, "сбор требований" обычно проводился на доске днем, обычно с кем-то из отдела, который больше всего использовал новое программное обеспечение. Был небольшой предварительный дизайн и много ре-факторинга и переписывания. Мы были очень довольны этим и создали около 100000 строк кода, которые хорошо спроектированы и стабильны.
Но, похоже, сейчас мы преодолеваем барьер сложности. Это очень расстраивает, потому что переход к более "тяжелым" процессам, чем хакерское и убивающее кодирование, приводит к значительному снижению производительности.
Это действительно сложные вопросы. Чтобы дать несколько точную оценку соотношения времени, которое вам необходимо подать на каждый шаг - если мы применяем классический подход к проектированию, внедрению, тестированию и развертыванию, - необходимо знать спецификацию и опыт участников проекта. Если вы возьмете книгу Макконнелла "Оценка программного обеспечения" (которую я настоятельно рекомендую), у вас есть глава об их исторических данных и о том, как использовать их для будущих проектов. Я не думаю, что у вас есть точные исторические данные прежних проектов - ну, у меня их нет - хотя я всегда напоминаю мне о записи их;) Поскольку самые мелкие ошибки или неопределенности на этапе проектирования являются наиболее важными Потратьте много времени, чтобы указать, что вы хотите сделать. Убедитесь, что все понимают это одинаково, и запишите это. Короче говоря, я бы выделил 50% - 75% времени на проектирование (если 75% это будет включать прототип, чтобы очистить все неопределенности) и равные части в реализации и тестировании. Если вы используете TDD, вы бы немного смешали дизайн и тестирование, чтобы взять немного фазы проектирования и добавить ее к фазе тестирования.
- Составление списка клиентов требует 1-2 дня
Это зависит от клиента и того, что ему нужно, и насколько хорошо он подготовлен. - Дизайнеры делают первоначальный набросок 2-3 дня
Здесь происходит небольшое ветвление, так как 2 и 3 будут происходить одновременно. - Программисты создают любую функциональность, которой еще нет в нашей существующей системе 1 день - 1 месяц
Это зависит от клиента и того, что ему нужно больше всего на свете.
Это также даст только функциональный код. - Повторяйте шаги 2 и 3, пока клиент не будет удовлетворен общим ощущением того, что мы имеем.
Может быть 1 итерация может быть 100 (маловероятно, если к 10 мы не сможем сделать их счастливыми, мы отправим их куда-нибудь еще). - Построить окончательный дизайн 1-5 дней
Это последний, без ошибок, действительный CSS/HTML/JS, все кросс-браузер и т. Д. - Сборка финальной функциональности 2-3 дня
Этот код "идеальный", он работает на 100%, он симпатичный, никаких известных ошибок нет, и разработчики с удовольствием его отправят
Это и Шаг 5 происходят одновременно. - Разверните 10 секунд.
Затем через 2 недели, 2 месяца и 6 месяцев мы делаем обзор, чтобы убедиться, что проблем не было.
Так что, если вы пропустите обзор, обычно это занимает 8-20 дней, подумайте IDK, как вы это сделаете за 100 дней.
Если мы просто создаем приложение (или расширяем его) для клиента, мы потратили бы 2-3 времени на ТОЧНОЕ определение того, что им нужно, и сколько бы времени ни потребовалось для его создания.
Только что нашел эту ветку, которая отвечает на "что" часть моего вопроса. По крайней мере, частично.