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

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

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

Я согласен со всеми, кто начинал с фразы"все зависит от проекта".

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

Обычно я следую этим основным принципам:

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

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

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

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

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

Когда мы беремся за новый проект " требования сбор " обычно проводился днем на доске, обычно с кем-нибудь из отдела, который больше всего использовал новое программное обеспечение. Там было мало первоначального дизайна и много перефакторинга и переписывания. Мы были очень довольны этим и сгенерировали около 100.000 строк кода, которые хорошо спроектированы и стабильны.

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

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

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

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

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

1. построение списка потребностей клиента 1-2 дня
       Это зависит от клиента, от того, что ему нужно и насколько хорошо он подготовлен.
2. дизайнеры делают первоначальный эскиз ИБП 2-3 дня
       Здесь происходит небольшое ветвление, так как 2 и 3 будут происходить одновременно.
3. программисты строят любой функционал, которого еще нет в нашей существующей системе 1 день - 1 месяц
       Это зависит от клиента, и что ему нужно больше всего остального.
       Это также только произведет функциональное код.
Повторяйте шаги 2 и 3 до тех пор, пока клиент не будет доволен общим ощущением того, что мы имеем.
    Может быть, 1 итерация может быть 100 (маловероятно, если к 10 мы не сможем сделать их счастливыми, мы отправим их куда-то еще.

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

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

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

---

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

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