craz
Нестандартное звание
мы хоть и не глупые, но сильно наивные будем ждать...
Имелось ввиду, что ошибка в одной абревеатуре не повод разговоров про кашу в голове. Закрыли тему)
Что за роадмап?
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Теория разработки проектов
- Автор темы craz
- Дата начала
Ну ты еще TDD и XP в один ряд поставил. Тоже странно
роадмап - буквально с англа "дорожная карта"(как вариант, когда путешествие планируешь, то вот этого числа будем в этом городе, а этого в этом). Что и когда планируется сделать в проекте. В моем случае - сначала реализовываем этот функционал. потом этот и т.д. Без особо мелких подробностей. Крупными мазками.
craz
Нестандартное звание
отличия я знаю)) одно частная практика другого. они стояли в ряду как практики, конечно говоря о tdd уже точно будет иметься ввиду хоть какой то xp или agileНу ты еще TDD и XP в один ряд поставил. Тоже странно
ага я погуглил нагуглил, но не понятно как из такого крупного мазка получить мелкую реализацию хотябы общей архитектуры, как происходить дальнейшая аппроксимация?
craz
Нестандартное звание
Да совершенно верно, но как бы то не было все выше сказанное, тоже достачно интересно(мне не в полной мере, я в частностях представляю передачу идеи от бредогенератора, до тех. спецеалистов). В любом случае наверное даже правильно, если дискуссия будет развиваться, что начали именно с этого. Если это все что вы можете посоветовать то этого конечно мало.Я так понимаю, его интересует не сколько реализация функционала, сколько стадия проекта от листа хотелок, до первой строки кода
craz
Нестандартное звание
Блин разработка через тестирование не возможна без использования других практик из экстремального программирования и аджайла, являясь частностью этих практик, вы разве так не считаете?Ты все-таки уточни... Про кашу я, похоже, не зря говорил
В тоже время я так думаю можно применять XP без TDD(имеется ввиду та его разновидность, которая связана в php с unit-тестированием) - хотя может это и перестанет быть XP в php... но как по мне не должно, как бы не выполнялись тесты, они в любом случае присутвуют и при тестировании без unit-тестирования
MiksIr
miksir@home:~$
Залог успешной команды - наличие опытного проектировщика, который умеет говорить на обоих языках - менеджерском и программерском, и его интуитивное знание, чем все это закончится Его задача - уточнить общие свойства черного ящика, выбрать те, которые как-то могут влиять на общую архитектуру, и приступить к детализации внутренностей черного ящика. Книжки то есть, но они про все те же патерны и uml и т.п., а уж как и что применять - опыт решает.
ИМХО
Его задача - уточнить общие свойства черного ящика, выбрать те, которые как-то могут влиять на общую архитектуру, и приступить к детализации внутренностей черного ящика. Книжки то есть, но они про все те же патерны и uml и т.п., а уж как и что применять - опыт решает.ИМХО
atv
Новичок
Самая трудная задача, это составить наиболее полный список требований, т.е. сформулировать задачу в полном объёме. А значит любое техническое решение (будь то даже структура файлов проекта), может подвергнуться изменению. Используя накопленный опыт проектировщики выделяют ТИПОВЫЕ ЗАДАЧИ и первоначально применяют решения для этих типовых задач (будь то та же структура файлов проекта).
Так как в процессе разработки требования постоянно уточняются или дополняются, то на первое место по значимости выходит ГИБКОСТЬ ПРОЦЕССА РАЗРАБОТКИ, которая позволит быстро вносить изменения на любом этапе разработки. В этом случае, проектирование ПРАВИЛЬНОЙ архитектуры на начальной стадии разработки уходит на второй план.
Так как в процессе разработки требования постоянно уточняются или дополняются, то на первое место по значимости выходит ГИБКОСТЬ ПРОЦЕССА РАЗРАБОТКИ, которая позволит быстро вносить изменения на любом этапе разработки. В этом случае, проектирование ПРАВИЛЬНОЙ архитектуры на начальной стадии разработки уходит на второй план.
MiksIr
miksir@home:~$
В моем понимании правильная - и есть гибкая
whirlwind
TDD infected, paranoid
У нас обычно начинается так:
1. Заказчик присылает никому непонятный документ примерно на пару страниц. Примерно такого содержания:
Партнерка
работа с товарами:
1.товар, категория,название,описание,картинко, себестоимость,минимальное количество штук
2. упаковка Описание,название и картинко из товара.Упаковка может состоять только из одного товара.
ценона, мин цена и колво товара
3. бандл, это набор упаковок который может состоять из упаковок разных товаров, характеризуется: название, описание,картинка,цена
4. Доставка. Тип доставки, характеризуется названием,описанием,себестоимостью,ценой,запрещенные страны,запрещенные
итп
По этому уже можно построить схему модели. Эта схема уже с последующих итераций, а начальная как правило гораздо проще.
Так же для управления моделью нужен интерфейс. Вот и план на первую итерацию: минимальная модель + интерфейс к ней. После первой итерации заказчик лезет тыркает кнопки, начинает четче представлять что он хочет, делает поправки и формулирует дальнейшие хотелки, которые кладутся в бэклог. Тимлид разбивает большие таски на маленькие, естественно что бы влазили как минимум в итерацию. Из бэклога задачи попадают в план следующей итерации. Приоритет задач согласовывается с заказчиком. И тд. На каждой итерации заказчик лезет в рабочий сайт, тыркает кнопки, получает впечатления, формулирует дальшейние хотелки и все продолжается по новому кругу. Всем удобно и никакой бюрократии и ТЗ, ХЗ.
1. Заказчик присылает никому непонятный документ примерно на пару страниц. Примерно такого содержания:
Партнерка
работа с товарами:
1.товар, категория,название,описание,картинко, себестоимость,минимальное количество штук
2. упаковка Описание,название и картинко из товара.Упаковка может состоять только из одного товара.
ценона, мин цена и колво товара
3. бандл, это набор упаковок который может состоять из упаковок разных товаров, характеризуется: название, описание,картинка,цена
4. Доставка. Тип доставки, характеризуется названием,описанием,себестоимостью,ценой,запрещенные страны,запрещенные
итп
По этому уже можно построить схему модели. Эта схема уже с последующих итераций, а начальная как правило гораздо проще.
Так же для управления моделью нужен интерфейс. Вот и план на первую итерацию: минимальная модель + интерфейс к ней. После первой итерации заказчик лезет тыркает кнопки, начинает четче представлять что он хочет, делает поправки и формулирует дальнейшие хотелки, которые кладутся в бэклог. Тимлид разбивает большие таски на маленькие, естественно что бы влазили как минимум в итерацию. Из бэклога задачи попадают в план следующей итерации. Приоритет задач согласовывается с заказчиком. И тд. На каждой итерации заказчик лезет в рабочий сайт, тыркает кнопки, получает впечатления, формулирует дальшейние хотелки и все продолжается по новому кругу. Всем удобно и никакой бюрократии и ТЗ, ХЗ.
тут большой минус - непредсказуемость
для заказчика: никто не знает сколько достижение цели в бизнесе потребует времени и денег, т.е. риски
для менеджера: никто не знает, захочет ли заказчик пойти на новый круг
для исполнителя: работа от забора до обеда без четких целей и перспектив, с авралами и накладками
риски неопределенности заказчик покрывает или мозгами (он сам умеет планировать), или высокой рентабельностью бизнеса, или низкой ценой вашей работы - а я уже комментировал, что зарплаты в твоей команде ниже аналогичных предложений специалистам нужного вам высокого уровня квалификации
я предпочитаю четко определять сроки своего проекта
whirlwind
TDD infected, paranoid
grigori а нам какая разница? Заказчик платит за итерацию. Не договорились - досвидос. Он не теряет за полгода разработки криворукими разработчиками, мы не теряем за полгода работы, которая не понравилась заказчику. Как раз это снижение рисков, я об этом уже говорил ранее в другом топике. Ну и для проектов за 5тыр это конечно не сработает. А определить сроки проекта, ну это знаешь - проект проекту рознь. Сроки для типовых проектов определить можно эмпирически на основе сроков исполнения предыдущих. Но не все проекты типовые. Каким образом ты с ходу с первого раза разработаешь новую красивую архитектуру, мне это, как человеку постоянно модифицирующему код, непонятно. То есть я так понимаю, что бы сказать цену, тебе надо знать сроки. Что бы знать сроки, тебе надо разработать архитектуру (а как иначе? из пальца?). Разработка архитектуры это оченно дохрена работы. Ты не берешь денег за разработку архитектуры?
ЗЫ. самое главное ты наверное не уловил. После каждой итерации заказчик получает РАБОЧИЙ продукт, который можно запускать и работать. Не через полгода, а после первой итерации. Это непредсказуемость?
Кстати, с чего ты взял, что зарплаты у нас маленькие? Из все вообще всех обратившихся претендентов, более-менее подходящим под наши требования оказалтся только один - Кос. Это за все вакансии, которые я тут размещал. Ты сам платишь высокую зп с тем что бы самому вытаскивать на себе проекты изза неопытных? Я нет. Но пока никто не жаловался, ни заказчики, ни разработчики. Ни за денег, ни за режима работы, ни за результат.
ЗЫ. самое главное ты наверное не уловил. После каждой итерации заказчик получает РАБОЧИЙ продукт, который можно запускать и работать. Не через полгода, а после первой итерации. Это непредсказуемость?
Кстати, с чего ты взял, что зарплаты у нас маленькие? Из все вообще всех обратившихся претендентов, более-менее подходящим под наши требования оказалтся только один - Кос. Это за все вакансии, которые я тут размещал. Ты сам платишь высокую зп с тем что бы самому вытаскивать на себе проекты изза неопытных? Я нет. Но пока никто не жаловался, ни заказчики, ни разработчики. Ни за денег, ни за режима работы, ни за результат.
whirlwind хорошо тебе, завидую белой завистью.
опишу мою ситуацию, в лучшем её варианте:
тз как такового от заказчика не добьёшься, приходится собирать список хотелок. большая проблема в том, что заказчик сам не понимает как работает его бизнес. чтобы описать его step by step. чтобы понять, что он ничего важного не пропустил лучше составить mind карту
http://www.mindmeister.com/ru/69386630/c-xix-xx
http://www.mindmeister.com/ru/67761449/mindmeister
садитесь и с заказчиком проходитесь по цепочке, просите чтобы он комментировал, а не смотрел с затуманенным взглядом.
хорошо бы составить прототипы в axure или просто html-лины
теперь надо продумать модели, делаешь в два прогона:
1. Составляешь список моделей и стрелочки между ними, можно в виде той же mind
2. добавляешь необходимые поля, здесь уже лучше mysql workbench
пытаемся сгенерить базу и модели. Идеально использовать Doctrine, тогда можно посадить отдельного человека на разработку моделей и их методов. Использование Query Builder-ов в контроллерах убивает смысл всех этих шагов. запретить и наказывать жесточайше, под каждый чих нужно выделять свой метод. (ИМХО).
теперь планируется какие роли(частично заложено на предыдущем этапе) и модули(контроллеры) у нас будут. Сортируешь по критичности для посмотреть. нужно стремиться, чтобы, как писал whirlwind, всегда можно было пощёлкать по ссылкам и кнопкам.
заводится трекер с задачами толстыми тикетами, дальше их начинаешь мельчить в подзадачи.
понеслось, делаешь, правишь, уточняешь, переделываешь, делаешь новое. не забывай вносить изменения в минд карты и тикеты.
очень хорошая практика устраивать митинги по 10-20 минут в начале дня, где каждый говорит что будет делать, какие проблемы возникли вчера. вечерние митинги не желательно.
опишу мою ситуацию, в лучшем её варианте:
тз как такового от заказчика не добьёшься, приходится собирать список хотелок. большая проблема в том, что заказчик сам не понимает как работает его бизнес. чтобы описать его step by step. чтобы понять, что он ничего важного не пропустил лучше составить mind карту
http://www.mindmeister.com/ru/69386630/c-xix-xx
http://www.mindmeister.com/ru/67761449/mindmeister
садитесь и с заказчиком проходитесь по цепочке, просите чтобы он комментировал, а не смотрел с затуманенным взглядом.
хорошо бы составить прототипы в axure или просто html-лины
теперь надо продумать модели, делаешь в два прогона:
1. Составляешь список моделей и стрелочки между ними, можно в виде той же mind
2. добавляешь необходимые поля, здесь уже лучше mysql workbench
пытаемся сгенерить базу и модели. Идеально использовать Doctrine, тогда можно посадить отдельного человека на разработку моделей и их методов. Использование Query Builder-ов в контроллерах убивает смысл всех этих шагов. запретить и наказывать жесточайше, под каждый чих нужно выделять свой метод. (ИМХО).
теперь планируется какие роли(частично заложено на предыдущем этапе) и модули(контроллеры) у нас будут. Сортируешь по критичности для посмотреть. нужно стремиться, чтобы, как писал whirlwind, всегда можно было пощёлкать по ссылкам и кнопкам.
заводится трекер с задачами толстыми тикетами, дальше их начинаешь мельчить в подзадачи.
понеслось, делаешь, правишь, уточняешь, переделываешь, делаешь новое. не забывай вносить изменения в минд карты и тикеты.
очень хорошая практика устраивать митинги по 10-20 минут в начале дня, где каждый говорит что будет делать, какие проблемы возникли вчера. вечерние митинги не желательно.
Мы с тобой мыслим разными категориями.
После итерации можно получить готовый продукт только в случае, если это работа по доработке/исправлению существующего кода.
Для поддержки твой алгоритм подходит, для новых проектов - нет.
>Что бы знать сроки, тебе надо разработать архитектуру
Не совсем. Надо отделить research. Затраты времени на разработку понятного мне функционала я корректно считаю без детальной разработки архитектуры, просто по краткому описанию функционала.
Уже навскидку называю цену, потом по часам детально выписываю по модулям, складываю, и сходится.
После итерации можно получить готовый продукт только в случае, если это работа по доработке/исправлению существующего кода.
Для поддержки твой алгоритм подходит, для новых проектов - нет.
>Что бы знать сроки, тебе надо разработать архитектуру
Не совсем. Надо отделить research. Затраты времени на разработку понятного мне функционала я корректно считаю без детальной разработки архитектуры, просто по краткому описанию функционала.
Уже навскидку называю цену, потом по часам детально выписываю по модулям, складываю, и сходится.
whirlwind
TDD infected, paranoid
grigori
> Уже навскидку называю цену, потом по часам детально выписываю по модулям, складываю, и сходится.
А что если ты ошибаешься? Или ты не ошибаешься никогда? Кто оплачивает неучтенное время? Разработчик в дедлайне? А заказчик автоматом переплачивает если вдруг вам времени поменьше понадобилось? Ну да, я тож знаю подход как рассчитать срок на весь проект: берем время примерно * 4 получаем срок в который уложимся делая работу неспеша. Поверь, еще никто не отказывался от итеративного подхода, как только узнавал все преимущества. Итеративный подход - требует заинтересованости всех сторон - все считают это справедливым, как минимум. Ну, кроме госконтор - но у них специфика изза законодательства.
> Для поддержки твой алгоритм подходит, для новых проектов - нет.
Ты как то странно утверждаешь, буд-то участвовал со мной в проектах. Поверь, фичекат в беклог делает чудеса.
> Уже навскидку называю цену, потом по часам детально выписываю по модулям, складываю, и сходится.
А что если ты ошибаешься? Или ты не ошибаешься никогда? Кто оплачивает неучтенное время? Разработчик в дедлайне? А заказчик автоматом переплачивает если вдруг вам времени поменьше понадобилось? Ну да, я тож знаю подход как рассчитать срок на весь проект: берем время примерно * 4 получаем срок в который уложимся делая работу неспеша. Поверь, еще никто не отказывался от итеративного подхода, как только узнавал все преимущества. Итеративный подход - требует заинтересованости всех сторон - все считают это справедливым, как минимум. Ну, кроме госконтор - но у них специфика изза законодательства.
> Для поддержки твой алгоритм подходит, для новых проектов - нет.
Ты как то странно утверждаешь, буд-то участвовал со мной в проектах. Поверь, фичекат в беклог делает чудеса.