С чего начать большой веб-проект?

#agile #scrum

Тематика e-commerce.
Проект достаточно большой, но согласно методикам "гибкой разработки", надо разбить
проект на спринты в 1-2 недели каждый.  

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

Но что-то я застопорился с началом. Как начинаю расписывать задачу для спринта по
функционалу, так сразу понимаю, что двумя неделями тут даже и не пахнет. Минимум месяц,
а то и два!  

Как обычно поступают в студиях, работающих по такой методике?
Быть может накидать интерфейс на "бумажке" и начать с этого(с front-end)?
Или с головой окунуться в самое сложное из функционала - и реализовывать это?
Или сразу сесть и начать продумывать структуру БД? (но есть опасность, что что-нибудь
важно упущу, а потом всю структуру переделывать заного).
Как же выстроить канбан?
    

Ответы

Ответ 1

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

Прототип - дает обратную связь. Схема базы - вообще никак.

Учтите, что скрам - это методология для команд от 5 до 9 человек. Целиком он вам
он не нужен.

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

Единственное, что я бы вам посоветовал (раз совсем не знаете, за что схватиться)
- начинать не с интерфейса или базы. А с расписывания основных user story. Выберите
из них самые важные, и реализуйте одну за одной (дописывая по необходимости тесты,
базу и код).


Ответ 2

По своему опыту могу сказать, что создание проекта начинается с дня х. В этот день
запускаешь yEd и прорисовываешь в нём всё что ты будешь делать буквально до мелочей.
Сразу же увидите какие задачи перед вами стоят. Не только визуализируете цель, но и
сразу увидите все дырявые места и на что уйдёт время. Зачастую случалось даже так,
что либо находились иные решения, либо менялм структуру или логику работы проекта.
Главное всё продумать, ровно на столько на сколько возможно, так как переделывать что-то
потом стоит огромного времени и денег.

Считай это как запуск ракеты, а ты инженер. Вроде и просчитать нужно а вроде и спешить
не надо, так как ошибёшься не взлетит. Но главное на самом деле - это тест и полёт.
Опыт полученный в процессе создания проекта даже лучше открывает на всё глаза нежели
многонедельные обдумывания.

По поводу с чего начать? Всегда необходимо начинать с сердцевины. Просто спрашиваешь
себя будет ли Х работать без У? Если нет пишешь У. Потом будет ли Н работать без Z
если нет то пишешь Z и наоборот. Таким способом найдёшь то с чего нужно начать. Бери
в пример вконтакте. Написали соц сеть, написали страницы вход выход, регистрация, забыли
пароль. запустились. прикрутили фотографии. прикрутили новости. в процессе работы поняли
каким должен быть софт и написали KPHP.

Удачи в проекте.


Ответ 3

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

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

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

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